You don't need a 500-page distributed-systems textbook to pass a system design interview. You need to be fluent in about 14 building blocks — and, more importantly, in the trade-off each one forces you to make out loud. Interviewers aren't grading whether you've memorized Kafka internals; they're grading whether you can reason about trade-offs under ambiguity.
Here are the 14, each with the one trade-off you'll actually be asked to defend.
The 14 concepts
1. Horizontal vs Vertical Scaling — Vertical = a bigger box (simple, hard ceiling). Horizontal = more boxes (elastic, but now you have distributed-systems problems). Say which and why.
2. Load Balancing — Spreads traffic across servers. The interview question is the algorithm (round-robin vs least-connections) and what happens to sticky sessions when a node dies.
3. Caching — The single biggest lever. Know where (client / CDN / app / DB) and the hard part: invalidation (TTL vs write-through vs write-back).
4. CDN — Cache static assets near users. Trade-off: freshness vs latency, and how you purge.
5. SQL vs NoSQL — Not "which is better" — which fits the access pattern. Strong consistency + relations means SQL. Massive scale + flexible schema means NoSQL. Justify from the requirements.
6. Database Indexing — Turns an O(n) scan into O(log n). Trade-off: faster reads, slower writes, more storage. Know when not to index.
7. Sharding / Partitioning — Split data across nodes when one DB can't hold it. The whole answer hinges on the shard key (and the hotspot problem when you pick it wrong).
8. Replication — Copies for availability and read-scaling. Trade-off: leader-follower (simple, replication lag) vs multi-leader (write availability, conflict resolution).
9. CAP Theorem — Under a partition, you choose Consistency or Availability. The senior move is naming which you'd pick for this system and why.
10. Consistency Patterns — Strong vs eventual vs causal. "Eventual is fine for a like count; not for a bank balance." Match the pattern to the data.
11. Message Queues — Decouple producers from consumers; absorb spikes; enable async. Trade-off: at-least-once + idempotency vs exactly-once complexity.
12. Rate Limiting — Protect the system. Token bucket vs sliding window, and where it lives (gateway vs service).
13. Consistent Hashing — How you add/remove nodes (cache or shard) without remapping everything. The classic follow-up to "how do you scale the cache?"
14. Microservices vs Monolith — Not a default, a trade-off. Monolith = simple, coupled. Microservices = independent scaling, operational overhead. Pick for the team and stage, not the resume.
How to actually use these in the room
- Start with requirements, not boxes. Clarify scale, read/write ratio, and consistency needs before drawing anything. Half of "failed" design interviews fail here.
- Every component you add, name its trade-off. "I'll add a cache, which buys read latency at the cost of invalidation complexity." That sentence is what gets you to the next level.
- Drive the conversation. Propose, then ask "does that match your constraints?" Interviewers grade collaboration as much as the diagram.
- Have one number per component. Rough QPS, storage, and latency estimates show you can reason about scale, not just name-drop.
The goal isn't a perfect diagram. It's to sound like someone who has made these trade-offs before.
I put the full one-page reference — with the patterns, the trade-off tables, and back-of-the-envelope numbers — here: System Design Interview Cheat Sheet: The 14 Concepts Every Candidate Needs.
Which of these trips people up most in your experience? I still think CAP gets hand-waved more than anything else.
Disclosure: I work on CoPilot Interview, an interview-prep tool — but this list stands on its own and the linked guide is free.
Top comments (0)