Designing for Scale — Requirements to Review

System design taught in the order the decisions actually get made. Constraints before boxes, numbers before technology choices, and a written trade-off before a diagram. The claim running through all twenty parts is the one from Part 1: the architecture is a consequence of the constraints, and if the constraints are not written down, the architecture is a guess wearing a diagram.

Who this is for

You can build a working service, but you stall when someone asks how it behaves at a hundred times the traffic, or you reach for a database because it is familiar rather than because the access pattern demands it. By the end you should be able to defend a design under questioning — which is a different skill from producing one.

Parts 1–4 are the load-bearing section. They are not warm-up. Every later part refers back to them.

---

The path

Foundations · Parts 1–4

The vocabulary and the arithmetic. Skipping this section is why most design discussions go in circles.

1. Requirements to Architecture — separating functional from non-functional requirements, and refusing to draw a box until the constraints are on the board.
2. Estimation That Constrains — back-of-envelope numbers that actually eliminate options rather than decorate the discussion.
3. The Storage Decision Tree — choosing a datastore from the access pattern instead of from habit.
4. CAP and the Consistency Spectrum — what you are really trading when you say "eventually consistent".

Classic designs · Parts 5–10

Six canonical problems, each one built from the constraints rather than recalled from memory.

5. URL Shortener — the deceptively simple one; key generation and read-heavy caching.
6. Distributed Rate Limiter — algorithms, and where the counter actually lives.
7. Chat and Real-time Communication — connection state, delivery guarantees, ordering.
8. Newsfeed and Fan-out — fan-out on write versus read, and the celebrity problem.
9. Typeahead and Search Autocomplete — latency budgets that rule out most architectures immediately.
10. Notification Systems — multi-channel delivery, retries, and deduplication.

Data systems · Parts 11–14

The pipelines under the product, where correctness problems are quietest and most expensive.

11. Real-Time Analytics — streaming aggregation and the freshness/cost curve.
12. Change Data Capture — getting data out of the operational store without dual writes.
13. The Data Lakehouse — table formats, and what they do and do not guarantee.
14. Metering and Billing — the system where an off-by-one is a refund, not a bug.

ML and LLM systems · Parts 15–18

Where the AI half of the stack meets the same constraints as everything else.

15. The Feature Store — training/serving skew, and why it keeps happening.
16. Model Serving — batching, autoscaling, and the tail latency you inherit.
17. RAG and Vector Search — retrieval as a systems problem rather than a prompt problem.
18. LLM-as-a-Judge and Release Gates — deciding whether a change is safe to ship.

Review · Parts 19–20

Two full design reviews, end to end, under the kind of questioning a real one attracts.

19. End-to-End Design Review I
20. End-to-End Design Review II

---

How to read it

Read Parts 1–4 in order and do not skip the arithmetic. After that, Parts 5–10 can be read in any order, though they are sequenced by increasing coupling. Parts 11–18 assume the foundations but not each other. Finish with 19 and 20 — they are the only two parts that test whether the rest actually landed.