Scalability: a capacity plan from scratch
Hands-on project: take a product brief, produce a full back-of-the-envelope capacity plan (QPS, storage, bandwidth, memory), then validate the Little's Law and queueing predictions with a tiny load test.
Reading that you should estimate before you design is not the same as producing a capacity plan a staff engineer would sign off on. Take a real-shaped product brief, estimate it end to end on paper, and then prove your two riskiest predictions — the throughput ceiling and the queueing knee — with a load test you write yourself.
This project makes the whole unit operational: you’ll do the estimation discipline for real, justify each design threshold with a number, and then measure to confirm the two predictions most likely to bite you — the throughput ceiling Little’s Law predicts and the latency knee the queueing curve predicts.
Produce a complete back-of-the-envelope capacity plan for a chosen product (e.g. a photo-sharing app, a URL shortener, or a chat service), then build a small load test that empirically validates your Little's Law throughput ceiling and the queueing-curve latency knee — closing the loop between estimate and measurement.
- A one-page capacity plan with QPS (avg + peak), storage/retention, bandwidth, and memory, every figure rounded to one significant figure and every assumption stated — readable in two minutes.
- An architecture-decisions list where each decision cites the specific number that drives it, including which resource breaks first and which data class dominates storage.
- A working load test whose measured maximum throughput matches the Little's Law prediction λ = L/W (within a stated tolerance), with the pool size and latency that produced it.
- A latency-vs-utilization plot (or table) that visibly shows the queueing knee — p99 flat to ~70% then climbing sharply — plus a one-line recommendation for the autoscaler target and the reasoning.
- A short write-up: one paragraph on what the estimate alone revealed before any measurement, and one on where the measurement differed from the napkin and why.
- Add a peak-and-retry scenario: inject a brief stall, enable client retries, and show how retries during saturation push offered load up and accelerate the queueing collapse — the brownout-to-outage feedback loop.
- Compare vertical and horizontal: run the same load against one large pool vs several small pools behind a round-robin balancer, and discuss where the USL coordination tax would start to bite at higher node counts.
- Add coordinated-omission awareness: run the load test once closed-loop (next request after the last returns) and once open-loop (fixed arrival rate), and show how the closed-loop p99 understates the true tail during a stall.
- Recompute the plan under a 10× growth assumption and identify the first threshold you cross (cache shard, DB shard, multi-region), demonstrating how an estimate changes the design as inputs scale.
- 01What four quantities does the capacity plan estimate, and how do you turn each into a design decision?
- 02How do you validate Little's Law and the queueing knee in a load test?
- 03Why estimate first and measure second, rather than just measuring?
This project turns the scalability unit into a repeatable workflow: take a product brief, estimate four quantities (QPS with a peak multiplier, storage over a retention window, bandwidth, hot-set memory) to one significant figure, and translate each into an architecture decision justified by a specific number — which resource breaks first, which data class dominates, where the thresholds (single box, single cache node, single DB primary) sit. Then close the loop with measurement: build a small service with a known pool size and controlled latency, validate that measured throughput matches the Little’s Law ceiling λ = L/W, and plot p99 against utilization to see the queueing knee the M/M/1 curve predicts, picking the autoscaler target from it. Doing the estimate first and the test second is the whole discipline — the napkin tells you the shape and the riskiest predictions; the load test confirms them. An engineer who has built this once sizes systems deliberately instead of discovering the ceiling during a 3 a.m. incident.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.