System Design Interviews: A Field Guide to the 12 Core Building Blocks

System design interviews feel infinite until you notice the pattern: almost every question is a recombination of the same components. Learn the dozen building blocks and the trade-offs between them, and "design Twitter" stops being scary.

The 12 you'll reuse forever

1. Load balancer — spreads traffic, hides failures
2. API / app servers — stateless, scale horizontally
3. Database — the source of truth; pick SQL vs NoSQL on access patterns
4. Cache — trade memory for latency; the hard part is invalidation
5. Queue — absorb bursts, decouple producers from consumers
6. Workers — do the slow work off the request path
7. CDN — push static bytes close to users
8. Object store — cheap durable blobs (images, video, backups)
9. Search index — inverted index for full-text and ranking
10. Rate limiter — protect the system from abuse and yourself from runaway cost
11. Observability — metrics, logs, traces; if you can't see it, you can't run it
12. Coordination — leader election, locks, consensus when you must agree

The three questions every design must answer

Strong candidates aren't the ones who name the most boxes. They're the ones who answer:

• Where does state live? Exactly one component should own each piece of truth.
• Where does feedback live? How do you know it works — or is silently failing?
• What's the blast radius? If a box dies, what breaks, and how is it contained?

Practice beats reading

You don't learn this by memorizing diagrams; you learn it by drawing one under a clock and getting it critiqued. Try a few:

• Design a rate limiter
• Browse the System Design domain — 1,000+ diagram-driven lessons
• Follow the System Design roadmap

Name the boxes, then defend the three questions. That's the whole game.