A short disclosure: I created Grokking the System Design Interview and the new System Design Patterns course, so I have a bias toward "take a course" as the answer. The list below is complete and useful without buying anything. I've also run over 500 system design interviews, which is where this particular selection of twelve comes from.
There are more than 60 named system design patterns. You do not need them all for an interview.
Watch enough system design rounds and a pattern emerges about the patterns: the same dozen ideas keep deciding the outcome. Not because interviewers conspire, but because every "design X" question, whether X is Instagram, Uber, or a payment system, forces the same fundamental problems: traffic has to be spread, reads have to be fast, data has to be split, failures have to be contained. The candidates who pass are the ones who reach for the right idea at the right moment and can defend the choice when pushed.
Here are the twelve, with the interview moment each one decides: the probing question it answers, and the mistake that costs candidates.
1. Load Balancing
The moment it decides: "How does traffic actually reach your servers?" Every design starts here, and interviewers use it as a warm-up that isn't really a warm-up.
Spreading requests across instances sounds trivial until the follow-ups: what algorithm (round robin, least connections, consistent hashing for sticky routing)? Layer 4 or layer 7? What happens when a server fails its health check mid-request?
The costly mistake: drawing the load balancer as a magic box. Saying "the LB handles it" to a follow-up is how a warm-up question becomes a red flag.
2. Caching (Cache-Aside)
The moment it decides: "Why is your read path fast?" and immediately after, "what happens on a miss, and how stale is your data?"
Cache-aside is the default: check the cache, fall through to the database, populate on the way back. Saying it is easy. Defending it means knowing your eviction policy, your TTL reasoning, and what invalidation strategy keeps the cache honest when writes happen.
The costly mistake: adding "a cache" without deciding what happens when a hot key expires and ten thousand requests miss simultaneously. That scenario, the cache stampede, is a favorite senior-level follow-up.
3. Sharding
The moment it decides: "One database can't hold this. Now what?" This is the scale conversation, and it's where mid-level candidates plateau.
The design choice that matters is the shard key. Shard users by ID and one celebrity's data still fits; shard tweets by author and the celebrity becomes a hot partition. Interviewers push on exactly this: skew, cross-shard queries, and resharding.
The costly mistake: choosing a shard key in two seconds. The interviewer heard "I've memorized that sharding exists"; they wanted the trade-off discussion the key choice forces.
4. Consistent Hashing
The moment it decides: the follow-up to sharding: "you add a fifth shard; what happens to the data on the other four?"
Naive hash-mod-N reshuffles nearly everything when N changes. Consistent hashing moves only a small fraction, and virtual nodes smooth the imbalance. This is a separator question: candidates who can explain the ring, not just name it, mark themselves as senior.
The costly mistake: naming the pattern without the mechanism. "We'd use consistent hashing" invites "great, how does it work?", and hand-waving there is worse than never mentioning it.
5. Primary-Replica Replication
The moment it decides: "How do reads scale?" followed by the trap: "a user writes, then immediately reads on a replica. What do they see?"
One primary for writes, replicas for reads, is the standard first scaling move. The interview substance is in replication lag and what it does to user experience, plus failover: what happens to in-flight writes when the primary dies.
The costly mistake: ignoring read-your-own-writes. The candidate who notices the lag problem unprompted, and offers a fix (read from primary after a write, session stickiness), just answered the actual question.
6. Message Queue
The moment it decides: "Your traffic just spiked 10x for one hour. What breaks?"
A queue between the request and the work turns a spike into a backlog: the system degrades to slower instead of down. It also decouples services, which is the answer to half the "how do these components talk" questions.
The costly mistake: queueing things that need synchronous answers, or never mentioning what happens when the queue itself backs up. Bounded queues, consumer scaling, and backpressure are the senior extensions.
7. Publish-Subscribe and Event-Driven Architecture
The moment it decides: "A user uploads a video. Five different systems care. How do they find out?"
Point-to-point calls turn one event into five coupled API calls and five new failure modes. Pub-sub inverts it: publish the fact once, and consumers subscribe independently. This is the backbone of every notification-system design, which remains one of the most-asked interview problems.
The costly mistake: not knowing delivery semantics. "At least once" means consumers see duplicates, which means you need idempotency (pattern 9), and interviewers love pulling exactly that thread.
8. Rate Limiting
The moment it decides: "How do you protect this API?" It's also a standalone interview question ("design a rate limiter"), which tells you how much interviewers care.
Token bucket handles bursts; leaky bucket smooths them; the interesting engineering is doing either across a fleet of servers, which drags in shared state, race conditions, and what to do at the limit (reject, queue, degrade).
The costly mistake: stopping at "we'd rate limit." Which algorithm, enforced where, and what does the client experience at the limit? The pattern only earns credit with its details.
9. Idempotency
The moment it decides: "The payment request timed out. The client retries. Did you just charge them twice?"
Idempotency keys make retries safe: the same operation applied twice lands once. In any design touching money, orders, or messages, interviewers will construct the double-fire scenario, and they're checking whether you built for it before they asked.
The costly mistake: treating it as an afterthought. Retries (pattern 10) without idempotency is an incident generator, and interviewers know the pairing better than most candidates.
10. Circuit Breaker (and Timeouts and Retries)
The moment it decides: "One downstream service starts failing. Walk me through what happens to everything else."
The failure-handling trio: timeouts stop infinite waits, retries with exponential backoff handle blips without stampeding, and the circuit breaker stops hammering a dependency that's down, giving it room to recover while you degrade gracefully.
The costly mistake: designing only the happy path. Senior interviews are substantially about failure, and the candidate who narrates failure handling unprompted is the one who gets the senior rating.
11. Quorum
The moment it decides: "You have three replicas. How many must acknowledge a write? A read? Why?"
Quorum is where consistency stops being a buzzword and becomes arithmetic: with N replicas, W write acks and R read acks, W + R greater than N gives you consistency through failures. It's the mechanism behind "tunable consistency" in systems like Cassandra and Dynamo.
The costly mistake: reciting CAP theorem instead. Interviewers at the senior bar want the concrete mechanism and its latency cost, not the triangle diagram.
12. CQRS
The moment it decides: "Your feed is read ten thousand times for every write. Does one data model serve both?"
Separating the write path from the read path, often with a denormalized read store built from events, is the answer behind news feeds, timelines, and dashboards. It pairs naturally with event sourcing and pub-sub in the designs interviewers actually ask.
The costly mistake: deploying it everywhere. CQRS earns its complexity only when read and write shapes genuinely diverge; recognizing when not to use it is part of the credit.
How to study these twelve
Three practical notes from the interviewer's side of the table:
Learn them as answers to questions, not as flashcards. Notice the structure of this post: every pattern is attached to a probing question. That's how interviews deliver them. Practice by taking a design ("design WhatsApp") and asking which of the twelve show up and where; the worked case studies in Grokking the System Design Interview drill exactly this, eighteen problems' worth.
Know each pattern's cost, not just its benefit. Every pattern above buys something and pays something: caching buys speed and pays in staleness, sharding buys scale and pays in cross-shard complexity, CQRS buys read performance and pays in eventual consistency. Interviewers probe the payment side. If you want the full treatment of each pattern including how it fails in production, that's what System Design Patterns: From Fundamentals to Real Systems was built for, including the 50 patterns beyond these twelve.
Chain them. Real designs are combinations: a notification system is pub-sub plus queues plus idempotency plus rate limiting. Practicing patterns in isolation is how you end up knowing all the words but no sentences.
Frequently asked questions
Which system design patterns are most important for interviews? The twelve above: load balancing, caching, sharding, consistent hashing, primary-replica replication, message queues, pub-sub, rate limiting, idempotency, the circuit-breaker failure trio, quorum, and CQRS. They recur because every interview problem forces the same underlying problems of traffic, data, speed, and failure.
Do I need all 60+ patterns for a system design interview? No. The full pattern reference matters for working engineers and for senior candidates closing blind spots, but interview preparation should start with the twelve and go deep rather than wide.
How do interviewers actually test pattern knowledge? Almost never by asking "what is a circuit breaker." They pose a design, wait for you to reach for a pattern, then probe its mechanism and cost: what algorithm, what failure mode, what trade-off. Naming patterns without mechanisms reads worse than not naming them.
What's the best way to practice these patterns? Worked problems with the pattern-per-moment habit: attempt a design, then check which patterns you missed and where. Grokking the System Design Interview structures 18 problems this way, and its free tier includes the AI design playground, which critiques your attempt before you see the solution.
Are AI infrastructure patterns showing up in interviews yet? Increasingly, yes: RAG pipelines, model serving, and semantic caching are appearing in loops at AI-heavy companies. They're in the full reference and covered in depth in the patterns course. For most general loops in 2026, the twelve above still carry the round.
Related reading
- The 60+ System Design Patterns, Organized: A One-Page Reference. The complete vocabulary these twelve come from.
- About Grokking the System Design Interview. The course that applies these patterns to 18 worked interview problems.
- The Complete Interview Guide. The 6-step framework the patterns plug into.
- How Long Does It Take to Prepare?. Study plans for 2-week and 6-week windows.
Practice reaching for the right pattern
Knowing the twelve is the vocabulary; interviews test the reflex. The free tier of Grokking the System Design Interview includes the AI design playground: attempt a design, get critiqued on which patterns you missed, then compare against the worked solution. It's the closest thing to interview reps that doesn't require scheduling a human.