Capacity, Cost, and the Bill

Capacity, Cost, and the Bill is the chapter that converts a design into a number somebody in finance can plan against, and it is missing from almost every treatment of system design because nobody pays for a whiteboard answer. The reader pays. That makes cost a design output rather than an operational surprise, and it makes the cost model an artifact you write.

Key takeaways

• A cost model is built from drivers with quantitative values and explicit formulas, and Microsoft's Azure guidance says to associate cost with business metrics such as cost per customer or cost per transaction.
• Throughput does not rise linearly and can go retrograde. Gunther's Universal Scalability Law puts maximum throughput at N equal to the square root of one minus alpha over beta.
• Contention and coherency are separate penalties. Contention flattens the curve, coherency pulls it downwards, and only the second one gets worse the more you scale.
• Reliability is a line item. The Azure guidance names redundancy, replication, performance headroom and recovery testing cadence as costs aligned to your SLOs and recovery objectives.
• Waste is measurable. Flexera's 2026 report, published 18 March 2026, puts estimated wasted cloud spend at 29 percent, the first increase in five years.

Read this after Chapter 10, whose instrumentation decisions determine which quantities you can divide by, and after Chapter 1, whose load model this chapter consumes without re-deriving. That division is deliberate: Chapter 1 owns demand shape, percentiles and growth and names no currency at all, and this chapter owns utilisation, unit cost and the bill. Chapter 9's cell count is priced here rather than there.

A design review approves an architecture in March. The infrastructure is provisioned in April and works well.

In September somebody in finance asks why the bill has grown 140 percent while traffic grew 60 percent. Nobody in the room can answer, because no formula was ever written that connects the two.

The architecture is fine. The absence is a cost model.

A cost model is an artifact with formulas

The word model matters. A list of last month's line items is a bill, and a bill explains nothing about what happens next.

Microsoft's Azure Well-Architected guidance on creating a cost model, recommendation CO:02, authored 15 November 2023 and updated 5 November 2025, describes the artifact directly. A cost model estimates initial cost, run rates and ongoing cost. It is built from cost drivers with quantitative values and explicit formulas. And it should associate cost with business metrics such as cost per customer or cost per transaction.

Those three properties are what make it useful in a design review. A formula can be challenged. A driver can be measured against reality next month. A cost per transaction can be compared against what a transaction is worth.

AWS's Cost Optimization Pillar, published 27 June 2024, frames the target similarly: a cost-optimised workload fully utilises all resources, achieves an outcome at the lowest possible price point, and meets your functional requirements. Note the third clause. It is what separates optimisation from degradation.

Throughput stops rising, and then falls

Capacity planning that assumes linear scaling produces a cost model that is wrong in the direction that hurts.

Gunther's Universal Scalability Law is published on the Performance Dynamics site, with the page updated 27 February 2020. Its three-parameter form gives X(N) as γN divided by (1 plus α(N minus 1) plus βN(N minus 1)). γ is single-unit throughput, α is contention, β is coherency. The important consequence is that maximum throughput occurs at N equal to the square root of (1 minus α) divided by β. After that point throughput decreases.

Put illustrative numbers through it. With α of 0.03 and β of 0.0001, the maximum sits at the square root of 9,700, which is about 98. Beyond roughly 98 concurrent units, adding more makes the system do less work while costing more per unit.

That is the shape every capacity model needs to respect. Not a straight line. A curve with a knee and a falling region behind it, and the falling region is where cost per successful request rises fastest.

Contention and coherency are different problems

The two parameters are worth separating because they have different fixes and different cost implications.

Contention is serialisation: work queuing for a resource only one unit can hold at a time. A lock, a single writer, a shared connection pool. Its penalty is proportional to N, so it flattens the curve without bending it downward, and it is usually fixable by removing the serialisation point.

Coherency is the cost of keeping copies consistent with each other, and its penalty grows with N squared. Cache invalidation traffic, cross-node consensus, replica synchronisation. That quadratic term is why the curve turns downward, and it is far harder to fix, because it is frequently the price of a correctness guarantee you chose in Chapter 3.

The design implication is uncomfortable and worth stating. A stronger consistency guarantee buys you a lower ceiling on useful concurrency, and that ceiling has a price attached.

Utilisation is the wrong headline number

Teams chasing cost reduction reach for utilisation first, and it is a poor primary metric for a reason the USL curve makes visible.

High utilisation looks efficient and sits close to the knee, where latency degrades sharply for small increases in load. Chapter 1's percentile target is what you are actually judged on, so running at 90 percent utilisation to save money is a decision to fail your latency SLO during every ordinary burst.

The better headline is cost per unit of useful work: per successful transaction, per active customer, per gigabyte served. Those numbers can go down while utilisation stays deliberately moderate, because they improve when you remove work rather than when you remove headroom.

The FinOps Foundation's framework, with materials dated March 2026, treats unit economics as a named capability in its Quantify Business Value domain, alongside forecasting and KPIs, with allocation sitting under Understand Usage and Cost. Naming it as a capability rather than a report is the right emphasis. It is something a team does continuously.

What actually drives the bill

This table is the artifact to lift. It pairs each driver with the design decision that moves it and the chapter where that decision was made.

Two of those five surprise people. Read amplification, because an index that made a query fast is charged on every write forever. And the cell count multiplier, because blast radius reduction is bought with fixed cost rather than with variable cost.

Cost per transaction, computed

The numbers here are round illustrative figures rather than fetched prices, and no price in this chapter should be treated as current for any provider.

Take an illustrative monthly bill of 40,000 dollars, split as 18,000 compute, 12,000 managed database, 4,000 data transfer, 3,000 storage and 3,000 observability. Take 90 million billable transactions in the same month. Cost per transaction is 40,000 divided by 90 million, which is about 0.044 cents.

Now do the same by customer. With 4,000 customer organisations, cost per customer is 10 dollars a month. Both numbers are useful and they answer different questions. The per-transaction figure tells you whether the design is affordable at ten times the volume. The per-customer figure tells you whether your smallest plan is priced above its cost to serve.

The most valuable thing this arithmetic produces is a ratio to watch. If the bill grows faster than transactions, some driver is superlinear, and the table above tells you which five candidates to check. That single ratio would have answered the question in September.

Reliability is a line item, not an attitude

The costs teams forget are the ones bought for events that have not happened yet, and the Azure guidance is specific about them.

It names redundancy, replication, performance headroom and recovery testing cadence as cost items in their own right. It says they should be aligned to your SLOs and to your recovery time and recovery point objectives. That is the sentence that turns a reliability conversation into a budget conversation with numbers on both sides.

Chapter 9's cell decision is priced exactly here. Eight cells means eight baselines and eight allocations of headroom, so the fixed portion of the bill multiplies while the variable portion stays roughly flat. Against that sits the cost of an outage reaching one hundred percent of customers instead of twelve and a half.

Both sides of that comparison belong in the record. A blast radius target with no price beside it is an aspiration, and a price with no blast radius beside it is a cut waiting to happen.

Waste is a measured quantity

The last piece is the number that makes this chapter urgent rather than theoretical, and it is survey data rather than a law.

Flexera's 2026 State of the Cloud Report was published on 18 March 2026, from a survey of 753 cloud decision-makers. It puts estimated wasted cloud spend at 29 percent, and reports that as the first increase in five years. It also reports that 76 percent of large enterprises now spend more than 5 million dollars a month on public cloud.

Treat the 29 percent as an industry estimate rather than as your number. The useful move is to measure your own equivalent, which requires the allocation the FinOps framework describes and the attributes Chapter 10 decided to emit. Untagged, unallocated spend cannot be classified as waste or as necessary, so it defaults to unexamined.

That is the design consequence. Cost allocation is an instrumentation decision, made at the same time as the tracing decisions, for the same reason.

The objection: finance owns the bill

The objection is organisationally true and it produces the September conversation every time.

Finance owns the budget and cannot own the drivers, because the drivers are architectural. Only the design team knows that the bill grew superlinearly because an aggregate is computed live per dashboard load. Or because a durability setting was raised for every write class rather than one. That knowledge does not exist in an invoice.

There is a sharper version of the point. A cost model is a design review artifact because it changes designs. A team that computes cost per transaction before building frequently finds that a proposed feature costs more per use than the plan it sits in. That is a product decision disguised as an infrastructure one.

So the split that works is simple. Finance owns the budget and the forecast. The design owns the drivers, the formulas and the reversal signal, which here is a ratio: the month the bill grows faster than the business metric it is divided by.

Chapter summary

A cost model is an artifact rather than an invoice, and Microsoft's Azure Well-Architected guidance on cost models, updated 5 November 2025, defines it as built from drivers with quantitative values and explicit formulas, and associated with business metrics such as cost per customer or cost per transaction. Capacity planning must respect a curve rather than a line, because Gunther's Universal Scalability Law gives throughput as γN over one plus α times N minus one plus βN times N minus one, with maximum throughput at N equal to the square root of one minus α over β, so with illustrative values of 0.03 and 0.0001 the ceiling sits near 98 concurrent units. Contention is proportional to N and usually fixable by removing a serialisation point, while coherency grows with N squared and is frequently the price of a consistency guarantee, so a stronger guarantee buys a lower ceiling on useful concurrency. Utilisation is a poor headline because it sits near the knee where latency degrades, and the FinOps Framework treats unit economics as a named capability. The five drivers that move a bill map back to decisions in Chapters 1, 2, 4, 6 and 9, with read amplification and the cell count multiplier the surprises. Reliability is a line item covering redundancy, replication, headroom and recovery testing cadence, Flexera's 18 March 2026 report puts estimated waste at 29 percent, and the chapter's decision is a written formula with a ratio that reverses it.

The design is now sized, guaranteed, bounded and priced. All of that assumed a system you are free to build, and the harder case is the one you are already running, where every change has to be safe in every intermediate state. Chapter 12 is Migrating a Running System.