Why learn system design from production architectures
Most system design material teaches building blocks in isolation: here’s a cache, here’s a queue, here’s a load balancer. That tells you what each part is, but not when you need it or what breaks without it.
In production, nobody adds a message queue because a diagram has one. They add it because checkout requests started timing out while a downstream service was slow. The use case comes first and the component second.
So this guide studies real companies’ architectures: what they built, what broke as they grew, and what they changed.
How every system design case study teaches
Every page follows the same sequence:
- The problem: the simplest design that worked at the time.
- The bottleneck: why it failed as traffic, teams or products grew, shown with numbers.
- The concept: the component or pattern that fixed it.
- The animation: run the new architecture and watch requests flow.
- The trade-offs: what it solved, and what new problems it created.
flowchart LR
P["1 · Problem<br/>simplest design"] --> B["2 · Bottleneck<br/>with numbers"]
B --> C["3 · Concept<br/>that fixes it"]
C --> A["4 · Animate<br/>the new flow"]
A --> T["5 · Trade-offs<br/>new problems"]
T -. "next bottleneck" .-> P
classDef s fill:#111a2e,stroke:#38bdf8,color:#e6edf7
class P,B,C,A,T s
How the case studies are organised
- One case study per company. Each company has its own section in the sidebar, with an overview page and a set of pages.
- Pages have subsections. Open a page in the sidebar to jump straight to any part of it.
- Facts are sourced. Company-specific claims link to the company’s own engineering publications, and each page marks which parts are documented and which are illustrative.