Your largest customer costs more to serve than they pay you. What do you do about that architecturally?

Earning the right to the claim

The sentence "this customer is unprofitable" is usually built on the total bill divided by the number of customers, weighted by a guess. That number cannot survive a commercial conversation, and if you take it into one you will lose the argument and the credibility. So the work starts with attribution, and attribution is an engineering problem that has to be solved before any architectural change is worth proposing.

Attribution needs a tenant identifier present at the point where cost is incurred, which means tagging or labelling every resource that can carry one, and for shared resources it means measuring usage per tenant rather than owning the resource per tenant. Request counts, bytes stored, bytes egressed, query time, rows scanned, messages published, and log and trace volume are the usual drivers, and the last one is the one people forget: a chatty integration can cost more in observability than in compute. Where a component genuinely cannot be attributed, say so and allocate it by a stated proxy rather than pretending to precision you do not have.

Then be honest about which kind of cost you are talking about. The marginal cost of this customer is what disappears from next month's bill if they leave tomorrow. The allocated cost includes their share of capacity you would still be paying for. These diverge sharply on reserved capacity, on a cluster sized for peak, and on any fixed platform spend, and conflating them produces the worst possible outcome: a customer terminated for unprofitability whose departure removes revenue and almost no cost.

Whose fault is the shape

With a per-tenant number you can ask the question that decides everything that follows: is this expensive because of what they do, or because of how you built it? The distinction matters because only one of the two is legitimately their bill.

Usage-shape causes look like a tenant whose data volume is an order of magnitude above the rest, an API integration polling every second where everyone else uses webhooks, exports of the full dataset every morning, or a retention requirement measured in years. Architecture causes look like a query that does a full scan because there is no index for the access pattern, a plan that keeps everything on the fastest storage tier for its whole life, per-request work that could be cached, or a cluster whose size is set by this tenant's peak while sitting idle the rest of the day.

Do the architecture side first, and do it before the commercial conversation, for a straightforward reason: you cannot credibly ask a customer to pay for your inefficiency, and every cost you remove by fixing your own design usually benefits every other tenant too. It also changes the negotiating position. Arriving with "we have already halved it and the remainder is genuinely driven by your export volume" is a different meeting from arriving with a complaint.

What architecture can actually change

There are four levers, and they differ in how much agreement they need.

Lever	What it changes	Whose agreement it needs
Efficiency work on the hot paths this tenant exercises	Cost per unit of the same work	Nobody outside engineering
Storage lifecycle, so cold data moves to cheaper tiers	Cost of data that is retained but rarely read	Product, if retrieval latency becomes visible
Quotas, rate limits and asynchronous alternatives for expensive operations	The shape of what the tenant is able to do	Product and the account owner, because it can be a contract change
Isolation onto separate infrastructure	Who bears the blast radius and who can be billed for it	Commercial, and it usually raises total cost

The lifecycle lever is the most consistently underused. Most systems keep every record on the same storage class from the day it is written until it is deleted, because that was the default at the beginning and nobody revisited it. Costs fall substantially when data is moved by age, and the design work is not the tiering itself but establishing which access patterns need old data quickly, which can accept a slower retrieval, and which can be reconstructed rather than stored.

Quotas deserve a caveat that candidates often miss. A limit introduced on an existing customer to control your costs is a reduction in what they bought, and imposing it unilaterally is a commercial act dressed as an engineering one. The defensible version is a limit that is in the contract from the start, applied to new customers, with existing ones migrated at renewal, and with an asynchronous or batched path offered for the operation the limit constrains so that the capability is not simply removed.

Isolation is worth naming as the option that raises cost and can still be right. A tenant whose load pattern makes capacity planning impossible for everyone else may be cheaper to serve on dedicated infrastructure, priced accordingly, than to keep absorbing into a shared platform sized for their peak.

The decision is not yours, and that is the point

Architecture supplies the evidence and the options; someone else decides whether to reprice, renegotiate, restructure or accept the loss. Being explicit about that division is what makes the recommendation actionable rather than an opinion. What the decision-maker needs is a per-tenant marginal cost with its method stated, a split between what you have already fixed and what remains inherent to their usage, and two or three costed options with their customer-visible consequences named.

And the recommendation must include the possibility that nothing changes. A reference customer in a segment you are entering, or an anchor account whose logo is doing commercial work elsewhere, can be worth serving below cost deliberately. That is a legitimate business decision and the architectural contribution is to make it a decision rather than an accident: measured, reviewed on a date, and with a stated threshold at which it comes back to the table.

Why per-tenant cost work stalls after the first month

The predictable failure is not getting the numbers wrong, it is building the attribution as a one-off investigation. Someone spends three weeks producing a spreadsheet, a decision gets made, and six months later nobody can reproduce it because the tagging was applied by hand and has since drifted. Cost attribution only pays back when it is continuous, which means tags applied by the deployment pipeline and enforced rather than requested, tenant identifiers carried through into logs and metrics from the beginning, and a per-tenant cost figure that appears next to revenue where the people who set prices will see it without asking.

The second failure is optimising the wrong end. The cost of a system is usually concentrated in a small number of drivers, and the drivers are frequently unglamorous: cross-zone data transfer, log retention, an over-provisioned non-production environment, snapshots nobody deletes. Engineering attention drifts towards interesting efficiency work on compute, while the largest line on the bill goes unexamined because it is dull. Rank by spend before you rank by interest.

Attribute the cost before you claim it, then split it into the part your design caused and the part their usage caused. Fix your own half first — it makes the commercial conversation credible, and it is the only half you are entitled to change on your own.