Capacity Planning Framework

Capacity planning answers three questions: how much can we handle, how much will we need, and how much margin do we want. A repeatable framework turns those answers into provisioning decisions before the traffic arrives.

How it works

The framework has four inputs and one output.

1. Supply model: the sustainable throughput of each resource, found through load testing, at the point where latency still meets the objective. Include the bottleneck resource: CPU, memory, connections, disk IOPS, network, or a downstream quota.
2. Demand forecast: baseline traffic, growth trend, seasonality, and planned events such as launches.
3. Headroom policy: extra capacity for failure tolerance, called N+1 or N+2, and for forecast error, often twenty to thirty percent.
4. Lead times: how long it takes to procure, approve, or raise quotas.

The output is a plan stating required units per resource at each date, who orders them, and the expected cost.

Utilization targets matter: running at sixty to seventy percent at peak leaves room for variance, whereas queueing delay rises sharply near saturation.

Implementation steps

1. Identify the critical resources and their limiting factors, including database connections and cloud quotas.
2. Run load tests per component to determine capacity per unit, and record the result with the software version.
3. Define a demand driver, such as active users or orders per minute, and relate resource load to it.
4. Forecast with at least two scenarios, expected and high.
5. Apply failure scenarios: capacity after losing the largest zone or node group.
6. Compute required capacity, compare with current, and raise orders and quota requests early.
7. Review monthly: compare forecast to actual and update assumptions.

Common pitfalls

• Planning only compute while the database or a third-party quota is the real limit.
• Using average load rather than peak.
• Ignoring that code changes alter per-unit capacity.
• Counting standby capacity that is also needed for failover by other workloads.
• Treating autoscaling as capacity planning; autoscaling reacts, it does not guarantee quota or database headroom.

Metrics to watch

• Peak utilization of each bottleneck resource versus target.
• Forecast error percentage over time.
• Headroom remaining in days at current growth.
• Cost per unit of demand, such as per thousand requests.
• Number of near-misses where limits were approached.

Example calculation

Peak forecast (next quarter):       12,000 req/s
Capacity per instance at p99 SLO:      400 req/s
Instances for peak:                  12000 / 400 = 30
Forecast error buffer (25%):          30 * 1.25  = 38 (rounded up)
Zone loss tolerance (3 zones, N+1):   38 / (2/3) = 57
Target peak utilization check:        12000 / (57*400) = 53%
Order: 57 instances; raise vCPU quota by 57 * 4 = 228

Key takeaways

• Capacity is measured by load test, not assumed.
• Plan for the bottleneck resource, not just compute.
• Build in explicit headroom for failures and forecast error.
• Account for lead times and quotas.
• Compare forecasts to actuals to improve every cycle.