Capacity Modelling
Predicting the resources a workload will need, from measured unit costs and a demand forecast, with deliberate headroom.
Definition
Capacity modelling connects business demand to infrastructure requirement: how much of each resource is needed to serve a projected load within the latency objective, with enough headroom to absorb variation and failure.
The method
1. Establish unit cost. From measurement, not estimate: CPU-seconds per request, database queries per request, bytes stored per user, connections per instance. Per endpoint, since costs vary by orders of magnitude.
2. Forecast demand. Business projections plus observed growth, with the shape included — daily peak-to-average ratio, weekly pattern, seasonal events. Peak matters, not average; average load has never sized anything.
3. Multiply, then add headroom. Headroom for growth between planning cycles, for forecast error, and — most importantly — for the loss of a failure domain. If you run three availability zones and must survive losing one, every zone must be able to carry 50% of total load, which means normal utilisation cannot exceed 66%.
4. Identify what has lead time. Autoscaling handles the elastic tier. Database capacity, reserved capacity, quota increases, specialised hardware and physical infrastructure have lead times measured in weeks. Those are the ones that must be forecast rather than reacted to.
The utilisation target
Do not plan to run at 90%. Queueing delay rises sharply as utilisation approaches saturation — roughly 4x the service time at 80% utilisation, 9x at 90% — so high utilisation buys cost efficiency at the direct expense of latency and of the ability to absorb a spike.
A common landing point is 50–70% at peak for latency-sensitive services, higher for batch work where latency does not matter.
What the model is really for
Not precision — it will be wrong. Its value is in producing an explicit statement of assumptions that can be checked as reality arrives: "we assumed 40 queries per order and 12% monthly growth". When performance surprises you, the model tells you which assumption broke, which is far faster than starting from scratch.
Failure scenarios
- Modelling on average load, so peak is unserved.
- No headroom for failure domain loss, so losing a zone takes the service down.
- Ignoring lead times, so the database cannot be scaled in the week it is needed.
- Assuming linearity. Costs are frequently non-linear — a dataset outgrowing memory changes behaviour discontinuously.
- Modelled once, never compared with what actually happened.
Interview question
"You run in three availability zones and must survive losing one. What is your maximum normal utilisation, and why?"