Capacity Planning
Size every component for the peak load you expect, with headroom, before you build it.
Why
A system that works at 100 users and falls over at 1000 is a system that wasn't capacity-planned. Capacity planning is the exercise of taking your expected peak load (requests/sec, GB stored, concurrent users) and sizing each component to handle 2-3x that with headroom, so the first traffic spike doesn't become an incident. It also surfaces the components that won't scale (the single-instance DB, the 1-region API) while you can still redesign. Skipping it means you discover your limits in production, at 3am, during the launch.
When
During system design, before provisioning. Takes half a day. Re-run before any expected >2x traffic event (launch, marketing push).
How
1. Define the peak load: RPS, concurrent users, GB stored, GB transferred - Use a 2-3x multiplier on the forecast peak for headroom 2. For each component, compute its limit: - API: RPS per instance × instance count; check CPU/conn limits - DB: connections, IOPS, storage; check max queries/sec - Cache: hit rate needed, memory for working set - Queue: messages/sec, retention, consumer throughput 3. Find the bottleneck (lowest headroom component) — that's where you'll break first 4. Either scale the bottleneck or redesign to remove it (e.g. add cache before DB) 5. Document the plan + the assumptions; revisit when actual load diverges > 30%
Example
Peak forecast: 5000 RPS, 200k concurrent, 2TB stored, 10TB/mo egress Component limits (with 3x headroom = 15k RPS target): API: 1500 RPS/instance → need 10 instances (have 4) ← BOTTLENECK DB: 3000 conn, 12k IOPS → queries OK, connections tight at 15k RPS Cache: 20GB working set, 95% hit → Redis r6g.large (25GB) OK Queue: 8k msg/s, 7-day retention → Kafka 3 brokers OK Action: scale API to 12 instances (2 spare), add DB connection pooler (pgbouncer). Bottleneck now: DB IOPS at 18k RPS — acceptable, monitor.
Common Problems
- ⚠Planning for average load, not peak — the system handles Tuesday afternoon and dies during the launch spike; always plan for peak × headroom.
Best Practices
- ✓Stress-test the plan with a load test at the planned peak before launch — assumptions are wrong 30% of the time and only a test reveals it.
- ✓Keep the capacity plan in the ADR so the assumptions (RPS/instance, hit rate) are auditable when they prove wrong.