Capacity planning
On this page 9 topics
Overview
Topics
- RPS
- concurrency
- data growth
- throughput
- storage estimates
Learn first
5 h of practice (estimate)
Learning outcomes
- Derive peak RPS, concurrency, and data growth from business forecasts.
- Estimate storage, network, and compute needs with back-of-the-envelope calculations.
- Validate estimates with load-test data and identify headroom per component.
- Present a capacity plan with assumptions, margins, and triggers for re-planning.
Lessons
- 01From business forecast to load
- 02Peaks, seasonality, and burst factors
- 03Back-of-the-envelope estimation
- 04Storage and data growth
- 05Headroom and saturation points
- 06Capacity plans people can act on
- 07Demo: sizing the order subsystem for Black Friday at 10×
- 08Demo: checking last year's capacity plan against reality
Lab and exercises
Lab
SRC-004-LAB1 · 10× capacity plan
Outcomes: 1–4 · Time: ~2.5 h
- Build the forecast chain from business numbers to peak RPS, concurrency, and write rate for orders, inventory, Kafka, and PostgreSQL.
- Estimate storage, network, and compute with multipliers (replication, retention, indexes).
- Compare with the MID load-test data; find saturation points and headroom per component, including N-1.
- Name the first bottleneck; write the plan with assumptions, margins, and re-planning triggers.
Acceptance: every number traceable to an assumption; first bottleneck named.
Exercises (timed estimation; six exercises)
| ID | Outcome | Task |
|---|---|---|
| SRC-004-EX01 | 1 | Finance forecasts 5x orders next year and 10x on Black Friday. Derive peak RPS from 150k orders/day, with explicit assumptions. |
| SRC-004-EX02 | 1 | Estimate concurrent users and database connections needed at that peak. |
| SRC-004-EX03 | 2 | Estimate yearly storage for an orders table (1 KB rows, 2M/day) with indexes, replicas, and backups. |
| SRC-004-EX04 | 2 | Estimate Kafka disk for 3,000 events/s of 1 KB, replication factor 3, 7-day retention. |
| SRC-004-EX05 | 3 | A load test shows PostgreSQL saturates at 4,000 TPS; peak need is 3,200 TPS with one replica lost. Compute headroom and decide. |
| SRC-004-EX06 | 4 | Write a re-planning trigger set for the plan. |
Show solutions
- EX01 Peak hour 12% of day gives 18k orders/h, about 5 orders/s; 10x gives 50/s; at 25 requests per order that is about 1,250 RPS, with a burst factor of 2 giving about 2,500 RPS design peak. Show the assumptions.
- EX02 Little's Law: concurrency = RPS x latency, so 2,500 x 0.1 s is about 250 in-flight requests; database connections depend on the share needing DB time and query time; verify with a pool model.
- EX03 2M x 1 KB = 2 GB/day, about 730 GB/year; indexes x1.5 is about 1.1 TB; two replicas multiply to about 3.3 TB; add backups and WAL margin.
- EX04 3,000 x 1 KB = 3 MB/s; x 86,400 s x 7 days is about 1.8 TB; x 3 replicas is about 5.4 TB cluster-wide.
- EX05 Headroom at full capacity is 20%, but if the lost replica shifted load the effective capacity may drop; if 3,200 is within 80% of 4,000, there is no N-1 margin; plan read offload or scale-up before the peak.
- EX06 For example: peak CPU above 60% for a week; storage projection reaches 70% in 90 days; requests per order drifts 20% from assumption; forecast revision from Finance.
Workplace evidence: a capacity estimate you produced and later compared with actual usage.
Quiz
Outcomes: O1 forecast to load · O2 estimation · O3 validation and headroom · O4 plan and triggers.
A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.
Practical part
Six estimation exercises SRC-004-EX01 to EX06 (timed) plus the lab. Pass: quiz at least 8/10, at least five exercises within a factor of 2 of the reference with visible assumptions, and a plan with the first bottleneck named.
Common mistakes
Averaging away peaks; forgetting replication and retention multipliers; no re-planning triggers.
Assessment
Timed estimation exercise.
Workplace evidence
A capacity estimate you produced and later compared with actual usage.
Career relevance
Large-scale performance (SRA-007) and cost architecture (ARC-021).