Capacity planning has a reputation as a forecasting exercise, which makes it sound like it requires predicting the future accurately. It does not. It requires knowing your current headroom, knowing how fast you are consuming it, and knowing how long it takes you to add more. Those three numbers do most of the work.
Headroom, not utilization
The common mistake is targeting a utilization figure. Seventy percent sounds responsible. But utilization on its own does not tell you how much load you can absorb before something breaks, because the relationship between load and latency is not linear. Systems degrade slowly and then suddenly, and the knee of that curve is what you actually want to know.
The more useful question is: how much additional traffic can this handle before the user-visible numbers move? You find out by testing, not by reasoning about percentages. Once you know it, headroom becomes a real quantity rather than a proxy.
Full utilization means no slack
A system driven at capacity has nothing left to absorb a surprise, and surprises are the normal condition. A retry storm, a slow dependency, a batch job somebody scheduled, a traffic spike from something outside your control. Each of these needs somewhere to go, and if there is no slack, they turn into queueing, and queueing turns into timeouts.
This is the same insight as an error budget, arrived at from a different direction. Deliberate slack is not waste. It is the capacity to survive the thing you did not plan for.
The three numbers
For each significant system, it is worth being able to answer:
- What is the current headroom, expressed as a multiple of present load rather than a percentage of some resource.
- How fast is load growing, measured over months rather than weeks so that seasonality does not dominate.
- How long does it take to add capacity, from noticing to serving traffic. Include the parts that are not automated, because those are usually the long pole.
If the time to add capacity is longer than the time until you run out, you have a problem now, not later. That comparison is the entire planning exercise, and most teams have never made it explicitly.
Autoscaling is not a plan
Autoscaling handles variation within a range you have already provisioned for. It does not help when the bottleneck is a database connection limit, a third-party rate limit, or a quota you have to email somebody to raise. Those are the constraints that actually bite, and none of them scale automatically.
It is worth writing down, once, what the real ceiling is and what component imposes it. Frequently it is not the thing everyone assumes.
Cost is part of the answer
Capacity and spend are the same conversation. Provisioning for a peak you see twice a year means paying for it all year, and that is sometimes correct and sometimes not. Making the trade explicit, rather than discovering it in a bill, is the difference between a decision and an accident.