Capacity Planning

The Google SRE Book's capacity planning model: predict demand, allocate resources, validate against reality.

Overview

Enough, but not too much

Capacity planning ensures you have the right resources for current and future load: not too much (wasted money) and not too little (outages).

SRE Book Ch 18: capacity planning is predictive, not reactive. By the time you're scaling under load, it's too late for non-trivial provisioning at rack, contract or region scale.

The three-step loop

1. Forecast demand — Historical traffic plus business projections, per resource, region and time window (peak hour differs from off-hour). Account for campaigns, holiday spikes, launches, pre-emptive client onboarding
2. Provision capacity — Translate the forecast into instances, CPU, memory, network bandwidth, storage IOPS. Cloud: reserved capacity, savings plans or just-in-time. On-prem: hardware with weeks-to-months lead times. Buffer for forecast error, typically 1.5×-2× for unbounded ranges, tighter for confident forecasts
3. Reconcile — Track actual vs forecast, adjust the model when reality differs, build forecasting skill iteratively

1 month — Tactical
1 quarter — Normal planning
1 year — Hardware procurement

Two key concepts (SRE Book Ch 18)

Resource fungibility — Can idle capacity move between workloads? Easy for cloud instances and multi-tenant Kubernetes pods; hard for dedicated machines per service. Higher fungibility means less buffer
Critical resource — The one that bottlenecks first: CPU, memory, network, disk IOPS, DB connections. Provision for it; everything else is over-provisioned by the same ratio

Demand drivers

Organic growth — User base grows X%/quarter: linear or growth model
Engagement — Existing users use more: project from per-user metrics
Product launches — New traffic patterns: estimate from staging tests and pilots
External events — Sales, holidays, news cycles: often prior-year data exists
Migration or consolidation — A service joining the platform: estimate from the source

Buffer for the unknown

Any forecast is a range. Provision for the upper bound, alert if you're tracking toward it, and rebudget if you're consistently above.

Tight: well-understood traffic, daily granularity — 10-20%
Medium: quarterly, mixed traffic types — 30-50%
Wide: new product, unknown adoption — 100%+, committed only as needed

Common failures

No forecast: "we'll buy more when we run out" — Works small; fails at scale because provisioning has lead time
Forecasting only the average — Peak hour matters more; plan for peak
Ignoring failure-mode capacity — N+1 in a 3-replica setup needs 1.5× peak-hour capacity to survive losing a replica at peak
Forecasting too far out — Beyond a year is mostly noise; re-plan quarterly

Key concepts

Forecast / provision / reconcile: Three-step loop. Forecast demand; provision resources; reconcile actual vs forecast; iterate.
Resource fungibility: Can spare capacity be swapped between workloads? Cloud: easy. Dedicated hosts: hard. Higher fungibility = lower buffer.
Critical resource: The first resource that becomes the bottleneck. Plan based on this; over-provision the rest.
Headroom / buffer: Capacity beyond peak forecast. 10-20% for tight forecasts; 100%+ for unknowns.
Failure-mode capacity: N+1 redundancy needs 1.5× peak (in 3-replica). Plan for peak DURING failure, not steady-state peak.

When to use it

Quarterly capacity reviews — what does the next 3 months look like?
Pre-launch — does the new service have provisioned capacity?
Pre-event — black friday, product launch, marketing campaign
Cost optimization — am I over-provisioned?

Interview questions

Walk me through capacity planning for a service.
What's the difference between average load and peak load capacity planning?
How do you calculate "failure-mode capacity"?