How do capacity models fail?

Every capacity model is a small theory of the system, and like most theories it fails at the boundaries of the data it was built from. The failures are patterned enough to enumerate, which means they are patterned enough to check for, which is the review's whole trade.

Which assumptions break first?

Averages, first and famously. The model that provisions for mean load meets a world that delivers peaks: the Monday morning, the marketing email, the retry storm that doubles arrivals in a minute. Peak-to-mean ratios of five are ordinary in consumer traffic; the histogram briefing makes the general case that distributions, not averages, are what systems experience. A model built on means is a model of a calmer company.

Linearity, second. The spreadsheet extrapolates: twice the traffic, twice the boxes. Real systems are linear until they are not, and the knee arrives wherever a shared resource saturates: the lock, the pool, the primary that replicas cannot help with writes. Queueing theory is unforgiving here; response time grows gently with utilization until roughly 80%, then turns vertical. Models that treat 95% utilization as "5% headroom" have mistaken a cliff for a lawn.

Third, the dependency the model forgot. Your service scales; its rate-limited vendor API does not. The load test proved the tier scales, in a lab where the payment provider was a stub with infinite patience. Production dependencies come with ceilings, quotas and backpressure of their own, and a capacity model that ends at your architecture's edge is a model of a system that does not exist.

And fourth, decay. The model was correct in March, for March's mix. By November the product added a feature that writes thrice per read, the mix shifted, and the model, still quoted in planning meetings, describes a retired system. Models age like diagrams: undated, they become folklore.

What does a model owe you to be trusted?

Stated inputs and a date. A peak-to-mean assumption written down. The knee located empirically, by load-testing to failure at least once (the number you find will not match the spreadsheet; that is the point of the test). Dependencies inventoried with their quotas beside them. And a re-run trigger: mix change, feature launch, or simply the calendar. A model with those properties is an instrument. Without them it is a hope with cells.

Our habit, transferable: keep the model small enough to be wrong legibly. Three drivers explain most systems (arrivals, cost per arrival, the binding constraint), and a one-page model that names them can be argued with, which is its purpose. The forty-tab spreadsheet is not more accurate. It is just harder to disagree with, and capacity planning fails socially before it fails mathematically.