The 14 system design concepts that cover ~80% of interviews

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

1. Start with requirements, not boxes. Clarify scale, read/write ratio, and consistency needs before drawing anything. Half of "failed" design interviews fail here.
2. 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.
3. Drive the conversation. Propose, then ask "does that match your constraints?" Interviewers grade collaboration as much as the diagram.
4. 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.