Capacity Planning and Headroom Workflow
Derive current utilization per resource, project demand growth from business signals, and size headroom against defined failure modes.
Objective
Size infrastructure to expected demand with measured headroom against specific failure modes, revisited on a schedule rather than after outages.
Environment
- Utilization metrics per resource (CPU, memory, connections, quota)
- Business demand signals (traffic, growth, seasonal patterns)
- A recurring planning slot and the ability to provision ahead of need
Steps
1. Measure utilization at the true peaks
Collect per-resource utilization at actual peak windows, not monthly averages, since capacity is consumed by peaks and averages hide them.
Expected state: A peak-utilization table exists per resource with the window it came from.
2. Identify the binding constraint
Determine which resource saturates first under growth: CPU, memory, connection pools, or external quotas, since that constraint sets the scaling strategy.
Expected state: The first-to-saturate resource is named with its current peak percent.
3. Project demand from business signals
Forecast demand growth from product signals (campaign calendar, user growth, seasonal peaks) rather than linear extrapolation of last quarter.
Expected state: A demand forecast exists with named assumptions per driver.
4. Size headroom against failure modes
Set headroom for the specific failure the headroom exists to absorb: node loss during peak, traffic spike multiple, failover concentration.
Expected state: Headroom is justified per failure mode, not a generic 2x.
5. Review on a schedule with triggers
Revisit the plan quarterly and on defined triggers (new major customer, product launch, utilization crossing 60 percent), updating forecasts and provisioning.
Expected state: The plan's age never exceeds a quarter, and trigger events reset it.
Expected outcome
Capacity sized from peak reality and business forecasts, with headroom justified per failure mode, reviewed on cadence instead of discovered by outage.
Verification
The next peak season fits within planned headroom without emergency provisioning; the binding constraint's projection matched observed saturation within tolerance.
Capacity is planned at the peak, provisioned before it
Monthly averages flatter the infrastructure: the peak hour consumes the capacity, the campaign consumes the headroom, and the outage consumes the weekend. Planning from peaks and business signals, with headroom justified per failure mode, gets provisioning ahead of need.
peak utilization (Tue 19:00-20:00, observed):
api CPU 61%
api mem 44%
db connections 71% pool 400/560 <- BINDING
cache memory 38%
demand forecast (business signals):
holiday campaign (Nov 15): +80% traffic, 14 days
user growth: +9%/qtr
new enterprise tenant (Q1): +12% steady
headroom sizing (failure-mode justified):
node loss at peak: N+1 within 30% of current
campaign spike: 1.8x peak traffic
-> provision: db pool 560 -> 900, api nodes 8 -> 13
review: quarterly + triggers (util>60%, launch, tenant)The binding constraint is not always compute
Teams add CPU nodes while the real ceiling is connection pools, queue depth, or a provider quota — utilization stays low on the scaled resource while saturation persists on the binding one. Naming the first-to-saturate resource directs spend at what actually limits throughput.
Headroom needs a named reason
Generic double capacity absorbs money but not necessarily the failure you will actually face: N+1 covers node loss, 1.8x covers the campaign spike, failover concentration needs the surviving cluster to hold the whole peak. Each headroom number should cite its failure mode, or it is a guess with a budget line.