Build a production capacity mindset that connects business demand, service limits, headroom, failure scenarios, scaling latency and cost.

What you should be able to do

• Explain this capacity concept in production terms.
• Connect demand, resource limits and safe operating capacity.
• Choose evidence that proves or disproves a capacity hypothesis.
• Make a scaling decision with explicit assumptions and failure margins.

Deep dive

Capacity planning answers a deceptively simple question: how much useful work can the system safely serve, now and later? The answer is not a CPU percentage. It is a chain from business demand to successful transactions, the resources required for those transactions, the bottleneck that caps throughput, and the reserve needed for bursts and failures.

Use a repeatable model: Demand → Capacity Unit → Saturation Point → Safe Operating Point → Headroom → Scaling/Failover Plan. Capacity must be measured against an SLO or business objective. A system that can process 20,000 requests/s with 15% errors does not have 20,000 requests/s of usable capacity.

Capacity is also time-dependent. A service that can add capacity in 30 seconds needs a different reserve than a stateful dependency that needs 20 minutes to provision and warm. Treat scaling latency, quotas, deployment limits and downstream constraints as part of capacity itself.

Commands / calculations / examples

Expected peak:        8,000 successful RPS
Measured safe/unit:     500 RPS
Base units:              16
Failure reserve:          4
Burst reserve:            4
Planned capacity:        24 units

The arithmetic is only the start; validate that shared databases, caches, queues and network paths can sustain the same peak.

Production decision rules

• Plan for successful business work, not raw request count.
• Headroom must reflect scaling latency and failure scenarios.
• The first shared bottleneck defines system capacity even if frontend instances have spare CPU.