Give every estimate a unit and a boundary
What This Concept Is
A capacity estimate relates demand to supply under explicit assumptions. Each number needs a unit, time window, workload definition and source. A count of users is not a request rate until activity and timing assumptions connect them.
Why It Matters Here
System-design estimates often look precise while hiding incompatible units. Average traffic, peak traffic, read/write mix and work per request affect different components. A design needs traceable assumptions before it needs a replica count.
Concrete Example
A fictional service receives 900 work units per second. A representative test suggests 200 work units/second per replica. The design policy allows using 3/4 of that reference capacity and requires tolerating one unavailable replica. The smallest count satisfies (N-1) × 200 × 3/4 >= 900, so N=7. Six would provide only 750 under that failure/policy combination.
This calculation assumes balanced identical work and linear scaling. It does not guarantee placement across failure domains, quorum availability or tail latency. If the 200-unit benchmark already incorporates the same headroom, multiplying by 3/4 again double-counts the margin. State exactly what was measured and what is policy.
Common Confusion / Misconception
CPU utilization, useful request throughput and storage bandwidth are different quantities. A single request may cause multiple downstream operations. Replication, indexes, retained versions and retries each change demand; they should not be bundled into an unexplained “safety factor.” Bytes and bits also differ by eight, before protocol overhead.
How To Use It
Keep an assumption ledger: variable, unit, baseline/range, source, affected component and verification method. Separate measured capacity from estimated demand and chosen operating margin. Use exact arithmetic for discrete sizing and round replica counts upward. Check the bottleneck dimension independently for CPU, memory, network and storage.
Check Yourself
Why does 900/200 rounded up not meet the stated failure policy? Which dimensions are missing from the fictional calculation? How can a headroom factor be counted twice? Is a larger object always a proportional increase in CPU work?
Mini Drill or Application
Build a unit-checked estimate for one original design prompt. Change traffic by 10x and object size by 100x separately. Name the assumptions that change and the first measurement needed to test your predicted bottleneck. Retain the baseline rather than replacing it with the new numbers.
Read This Only If Stuck
Fundamentals of Software Architecture — quality tradeoffs. Google SRE's Non-Abstract Large System Design reinforces concrete, iterative capacity reasoning. The numerical example here is fictional teaching data.