system-design · advanced

Capacity Planning for Backend Services

Quick answer

Capacity planning forecasts demand and sizes compute, storage, queues, and dependencies so peaks meet SLOs. It combines historical load, growth, headroom, and failure scenarios—not guesswork on launch day.

Why this matters

Learning objectives

  1. Build a demand model. 2. Convert demand to resource needs. 3. Plan headroom and failover capacity. 4. Validate with load tests. 5. Revisit after product changes.

Explain like I am 5

Before a party, count guests and plates—and keep extras if some plates break.

Mental model

flowchart LR
  Traffic --> Model
  Model --> Resources
  Resources --> Headroom
  Headroom --> Test[Load test]
  Test --> Adjust

Core concepts

Demand model

RPS, payload size, fan-out, peak/average ratio, seasonality.

Little's law intuition

Concurrency ≈ arrival rate × latency; latency spikes explode concurrency.

Headroom

Plan for N+1 or regional failover, not only sunny-day peak.

Dependency capacity

Your service can be fine while Postgres connections or Kafka lag melt.

Continuous planning

Re-plan after launches, viral events, and architecture changes.

Worked example

Checkout peaks 3× daily average. p99 200ms target. Load test shows DB CPU 85% at 2× → index + read replica before marketing campaign; alert on connection pool wait.

Trade-offs

Huge always-on bufferJust-in-time only
CostlyPeak risk

Failure modes

ModeMitigation
Average-only sizingPeak + failover
Ignoring dependenciesJoint capacity reviews
No load testsPre-prod peak rehearsal

Interview mode

Skeleton: "Model peak demand, map to resources and dependencies, keep failover headroom, prove with load tests."

Knowledge check

Peaks—not averages—drive outages and sizing

Averages always equal peaks

It only matters for CSS

It removes the need for monitoring

By Shubham Jain

All articles

Shubham Jain · Learning Lab