Core idea
Every large system started as one box running everything. It grows by repeatedly asking: what is the next thing that breaks? The answer picks the next component.
Step by step
Step 1 of 11: One server
Everything runs on one machine. Fine for a hundred users, but one crash takes the whole site down.
Mental model
Think of a food stall becoming a restaurant chain. First you cook and serve alone (single server). Then you hire a cashier and move the kitchen out back (separate web and data tiers). A host seats guests across tables (load balancer). A spare kitchen copies every recipe (replication). A pre-made counter holds popular dishes (cache). Branch shops serve nearby neighbourhoods (CDN, data centers). A ticket rail decouples ordering from cooking (queue).
Why it matters
- It gives you a natural order for explaining any design out loud
- Each component exists to fix a specific failure, so you can justify it
- Interviewers reward incremental reasoning over a memorized final diagram
What to know
- 1. Single server: web app, database and cache all together; DNS turns the domain into the server’s IP
- 2. Split web tier and data tier so they scale independently
- 3. Pick the database: relational by default; consider NoSQL for very low latency, unstructured data or massive volume
- 4. Add a load balancer and more web servers for availability and capacity
- 5. Add database replication: one primary takes writes, replicas serve reads and act as failover
- 6. Add a cache for hot reads and a CDN for static files
- 7. Make the web tier stateless so it can auto-scale
- 8. Add a second data center with geo-routing
- 9. Add message queues to decouple slow work from user requests
- 10. Add logging, metrics and automation as the team and system grow
- 11. Shard the database when one primary can no longer hold the data or the writes
Common traps
- Drawing the final architecture in the first minute without saying what problem each box solves
- Adding sharding or multi-region before a cache and replicas have run out of road
- Forgetting that every new component can itself fail, so ask what happens when it dies
Recognise it
Recognition trigger: ‘Design a system for millions of users’ → walk the ladder. At each step state the symptom (single point of failure, slow reads, huge table) and the one component that cures it.
Practice question
Start with one server and 100 users. Walk me through each change as you grow to 10 million users, and say what breaks at each step.
Apply at work
Answer these for the system you work on.
Go deeper
- System Design Primer (opens in a new tab) · GitHub (donnemartin)
- Chapter 1: Reliable, Scalable and Maintainable Applications · Designing Data-Intensive Applications (Kleppmann), book