Capacity Planning

Estimate vs Plan

Capacity estimation answers “how much for today?” once. Capacity planning is the ongoing discipline: how much headroom is policy, when does the next purchase/shard happen, and what signals trigger it — before saturation, not after.

 THE PLANNING LOOP

 measure actuals → compare vs plan → adjust forecast
        ▲                                │
        │        trigger thresholds      ▼
        └──────── order/enable capacity ◄┘
 
 run continuously; estimates decay as traffic grows and shapes shift

Headroom Is Policy, Not Vibes

Pick utilization ceilings deliberately per tier:

Tier	Target max sustained	Rationale
Payments/critical	50–60%	Must absorb peak + node loss + deploy simultaneously
Core APIs	~70%	Standard N+1 slack
Batch/analytics	85–90%	Latency-tolerant; efficiency matters more

Headroom must survive the worst credible moment: peak traffic + one node down + a rolling deploy in progress. Sizing that only fits sunny operation is under-provisioned by definition.

Growth Runway

Every tier needs an answer to “when do we buy next?”:

 TRAFFIC GROWTH vs CAPACITY (illustrative)

 capacity ────╮        ╭── new purchase lands
              ╵        ╵
 demand ──────╳━━━━━━━━╳━━━━━ ← saturation if late
              
 lead time rules:
 - autoscale handles minutes-scale variance only
 - provisioned DB upgrades take days–weeks
 - sharding projects take months ← start at 60% sustained, not 95%

The planning artifact is a runway table per component: current load, ceiling, weeks-of-runway at observed growth, and the action date.

Signals That Trigger Action

Signal	Threshold example	Action
Sustained CPU/utilization	above 70% for a week	Add nodes / re-examine scaling path
p99 latency drift upward	trending past SLO buffer	Capacity or efficiency investigation
Storage growth projection	crossing 70% within 2 quarters	Archive tiering / shard design starts
Connection saturation	pool waits visible	Pooler/proxy before bigger instance
Peak factor widening	events spiking harder	Pre-provisioning + load shedding plans

Autoscaling changes timing, not planning: reactive tiers cover minutes-scale variance; databases, caches with warm-up costs, and shard boundaries remain scheduled decisions.

The Cost Tension, Managed

Provision-for-peak vs pay-for-average is the standing conflict. The managed resolution stack:

 baseline     reserved/scheduled capacity ≈ average × small buffer
 variable     autoscaling group between floor and peak ceiling
 overflow     load shedding + degradation for beyond-ceiling events
 
 cost = f(how flat you can make the curve) — smoothing demand
 (off-peak pricing, regional staggering) beats buying peaks

Interview Framing

Seniority shows in the process references: naming utilization targets per tier, runway thinking (“at 20% MoM growth this DB hits its ceiling in Q3 — sharding design should start now”), and autoscaling’s reaction-lag limitation. A candidate who only computes today’s node count has estimated; one who describes when the next decision fires has planned.