A short disclosure: this page mirrors the structure of System Design Patterns: From Fundamentals to Real Systems, a course I built, where each pattern is a full lesson. Everything on this page is free and complete on its own. The course is where each one-line definition becomes actual understanding, with production failure stories and a capstone design per chapter.
Every scalable system ever built is a combination of a surprisingly small set of ideas. Load balancers spread the traffic. Caches absorb the reads. Queues absorb the spikes. Shards split the data. Circuit breakers contain the failures. Once you can name these ideas, an architecture diagram stops being a collection of boxes and becomes something you can read.
This page has three parts:
- The complete reference. All 62 patterns in 10 categories, each with a one-line definition.
- The 12 that decide most interviews. The prioritized subset, with the exact question each one answers and the mistake that costs candidates.
- How to learn them properly, including which course to take first if you are also preparing for an interview.
Part 1: The complete reference
1. Communication patterns
How services talk to each other, and what breaks when they do.
| Pattern | What it does |
|---|---|
| Request-Response | The synchronous default. Simple, but couples the caller's latency to the callee's health. |
| Message Queue | Puts a buffer between services so a traffic spike becomes a backlog instead of an outage. |
| Publish-Subscribe | One event, many independent consumers, none of which know about each other. |
| Event-Driven Architecture | Services react to facts that happened instead of calling each other directly. |
| Webhooks | Push notifications between systems, replacing constant polling. |
| Server-Sent Events | One-way live updates over plain HTTP: scores, feeds, dashboards. |
| Bidirectional Streaming | A full two-way conversation over WebSockets, for chat, collaboration, and games. |
2. Data and storage patterns
Where the data lives, how it is split, and how changes survive crashes.
| Pattern | What it does |
|---|---|
| Primary-Replica | One node takes writes, copies serve reads. The first move for read-heavy systems. |
| Sharding | Splits data across machines when one machine cannot hold or serve it all. |
| Consistent Hashing | Assigns data to shards so adding a node does not reshuffle everything. |
| Write-Ahead Log | Writes the intent down before acting on it, so a crash loses nothing. |
| Event Sourcing | Stores every change as an event; current state becomes a replay. |
| CQRS | Separates the write model from the read model when the two pull in different directions. |
3. Caching patterns
The difference between a fast system and a database under fatal load.
| Pattern | What it does |
|---|---|
| Cache-Aside | The application checks the cache first and loads from the database on a miss. The default. |
| Read-Through | The cache itself fetches on a miss: simpler application, smarter cache. |
| Write-Through | Writes go through the cache so it is never stale, paid for in write latency. |
| Write-Behind | The cache absorbs writes and flushes them later: fast, with a durability risk. |
| Cache Stampede Prevention | Stops a thousand simultaneous misses from crushing the database when a hot key expires. |
4. Resilience patterns
Everything fails. These decide whether anyone notices.
| Pattern | What it does |
|---|---|
| Timeout | Never wait forever. The simplest failure containment there is. |
| Retry with Exponential Backoff | Retries without turning a brief failure into a self-inflicted denial of service. |
| Idempotency | Makes retries safe, so charging the card twice cannot happen. |
| Circuit Breaker | Stops calling a failing dependency so it can recover and you can degrade cleanly. |
| Bulkhead | Isolates resource pools so one failing feature cannot take down the rest. |
| Dead Letter Queue | Quarantines messages that keep failing instead of letting them block the queue. |
| Graceful Degradation | Decides in advance what the product does when a dependency is down. |
5. Scaling patterns
From one server to a million requests per second.
| Pattern | What it does |
|---|---|
| Vertical Scaling | Buy a bigger machine. Underrated up to a point, and a dead end past it. |
| Horizontal Scaling | Add more machines. Requires statelessness and something to spread the load. |
| Load Balancing | Spreads requests across instances; algorithms and health checks decide how well. |
| Auto-Scaling | Matches capacity to load automatically instead of provisioning for peak. |
| Database Connection Pooling | Reuses connections. The quiet fix behind many "the database is slow" incidents. |
6. Coordination and consistency patterns
Getting multiple machines to agree, which is harder than it sounds.
| Pattern | What it does |
|---|---|
| Two-Phase Commit | All-or-nothing across services, bought with blocking and coordinator risk. |
| Saga | A distributed transaction as a chain of local steps, each with a compensating undo. |
| Quorum | Agreement from a majority, so reads and writes stay consistent through failures. |
| Vector Clocks | Tracks causality so concurrent updates can be detected instead of silently lost. |
7. Edge and API patterns
The entry point of the system, and everything that guards it.
| Pattern | What it does |
|---|---|
| Reverse Proxy | TLS, compression, and routing handled before requests reach your application. |
| CDN | Serves content from the edge, near users, instead of from your origin every time. |
| API Gateway | One entry point handling authentication, routing, and throttling across services. |
| Backend for Frontend | A tailored API layer per client type instead of one generic layer for all. |
| Rate Limiting | Token bucket and its relatives: protects the system from overuse, malicious or accidental. |
| Cursor-Based Pagination | Pagination that stays correct at scale, where offset pagination fails. |
| API Versioning | Evolves an API without breaking the clients already using it. |
| Sidecar | Adds cross-cutting concerns to a service without changing its code. |
| Service Mesh | Sidecars everywhere, managed centrally: traffic control between all services. |
8. Operations and delivery patterns
Shipping and running systems without overnight emergencies.
| Pattern | What it does |
|---|---|
| Health Check Endpoint | Lets infrastructure ask whether a service is healthy and act on the answer. |
| Distributed Tracing | Follows one request across a dozen services to find the slow step. |
| Blue-Green Deployment | Two environments, instant switch, instant rollback. |
| Canary Deployment | Releases to 1% first and lets the metrics decide the rest. |
| Feature Flags | Separates deploying code from releasing features. |
9. Data processing patterns
When the data is bigger than any one machine, or never stops arriving.
| Pattern | What it does |
|---|---|
| MapReduce | Splits a huge batch job across many machines, then merges the results. |
| Stream Processing | Computes on data as it arrives instead of batching it for later. |
| Lambda and Kappa | The architectures for combining, or replacing, batch and streaming. |
| Change Data Capture | Turns database changes into an event stream other systems can consume. |
| Exactly-Once Semantics | What it actually takes to process an event once: not zero times, not twice. |
| Backpressure | Lets slow consumers push back instead of being overwhelmed. |
| Partitioned Consumption | Parallelizes a stream while keeping per-key ordering. |
10. AI infrastructure patterns
The newest part of the vocabulary, and the one interviews are adding fastest.
| Pattern | What it does |
|---|---|
| Feature Store | One consistent source of machine learning features for both training and serving. |
| Model Serving | Inference behind an API, with latency and versioning guarantees. |
| GPU Auto-Scaling | Scales scarce, expensive compute without paying for idle capacity. |
| LLM Gateway | One control point for model routing, cost caps, and fallbacks. |
| Semantic Caching | Caches model answers by meaning rather than by exact string match. |
| Vector Database Sharding | Scales similarity search past one machine. |
| RAG Pipeline | Retrieval plus generation: grounds model answers in your own data. |
Part 2: The 12 patterns that decide most interviews
You do not need all 62 for an interview.
Watch enough system design rounds and the same dozen ideas keep deciding the outcome. Not because interviewers coordinate, but because every "design X" question, whether X is Instagram, Uber, or a payment system, forces the same underlying problems: traffic has to be spread, reads have to be fast, data has to be split, failures have to be contained.
Here are the twelve, with the interview moment each one decides and the mistake that costs candidates. This selection comes from more than 500 system design interviews I have personally conducted.
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 is not really a warm-up.
Spreading requests across instances sounds trivial until the follow-ups arrive: which algorithm, round robin, least connections, or consistent hashing for sticky routing? Layer 4 or layer 7? What happens when a server fails its health check mid-request?
The costly mistake: describing the load balancer as a box that handles it. Saying "the load balancer takes care of that" to a follow-up turns a warm-up question into a warning sign.
2. Caching, specifically 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 at the same moment. That scenario, the cache stampede, is a favorite senior-level follow-up.
3. Sharding
The moment it decides: "One database cannot hold this. Now what?" This is the scale conversation, and it is 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 on a node; 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 that you have 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 out 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 would use consistent hashing" invites "great, how does it work?", and being unable to answer 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 from a replica. What do they see?"
One primary for writes and replicas for reads is the standard first scaling move. The interview substance is in replication lag and what it does to the 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 without being prompted, and offers a fix such as reading from the primary after a write or using session stickiness, has answered the actual question.
6. Message Queue
The moment it decides: "Your traffic just increased tenfold for one hour. What breaks?"
A queue between the request and the work turns a spike into a backlog: the system degrades to slower rather than down. It also decouples services, which answers half the "how do these components talk" questions.
The costly mistake: queueing work that needs a synchronous answer, 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. Publish-subscribe 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 delivery means consumers see duplicates, which means you need idempotency, and interviewers reliably pull exactly that thread.
8. Rate Limiting
The moment it decides: "How do you protect this API?" It is also a standalone interview question, which tells you how much interviewers care about it.
Token bucket handles bursts, leaky bucket smooths them, and the interesting engineering is doing either across a fleet of servers, which brings in shared state, race conditions, and what to do at the limit: reject, queue, or degrade.
The costly mistake: stopping at "we would 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 are checking whether you built for it before they asked.
The costly mistake: treating it as an afterthought. Retries without idempotency generate incidents, and interviewers know that pairing better than most candidates.
10. Circuit Breaker, with 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 brief failures without overwhelming the dependency, and the circuit breaker stops calling a service that is down, giving it room to recover while you degrade gracefully.
The costly mistake: designing only the path where everything works. Senior interviews are substantially about failure, and the candidate who describes failure handling without being asked 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 term and becomes arithmetic: with N replicas, W write acknowledgements and R read acknowledgements, W plus R greater than N gives you consistency through failures. It is the mechanism behind tunable consistency in systems like Cassandra and Dynamo.
The costly mistake: reciting the 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 publish-subscribe in the designs interviewers actually ask about.
The costly mistake: using 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.
Part 3: How to actually learn these
Three habits that turn the list into ability
Do not memorize down the list. Connect across it. Real designs chain patterns: a notification system is publish-subscribe plus a message queue plus idempotency plus rate limiting. When you study one pattern, ask which others it usually travels with. Practicing patterns in isolation produces someone who knows all the words and cannot form a sentence.
Interrogate every pattern the same way. What problem does it solve? What does it cost? How does it fail? When is it the wrong choice? A pattern you cannot argue against is a pattern you do not understand yet, and interviewers use exactly this test.
Learn them as answers to questions, not as flashcards. Notice the structure of Part 2: every pattern is attached to a probing question. That is how interviews deliver them. Practice by taking a design, such as "design WhatsApp", and asking which patterns show up and where.
The course that teaches all 62 in depth
System Design Patterns: From Fundamentals to Real Systems is the course this reference mirrors. It is the first Design Gurus course built for every engineer who works on systems rather than only for interview candidates.
| At a glance | |
|---|---|
| Full name | System Design Patterns: From Fundamentals to Real Systems |
| Patterns | 62, across 10 chapters |
| Structure | Foundations, then pattern chapters with a capstone design each, then 4 full system designs |
| Content | Roughly 20 hours, self-paced |
| Newest material | A dedicated AI infrastructure chapter: RAG, LLM gateways, semantic caching, model serving |
| Audience | Backend, data, and AI engineers, for interview preparation and day-job depth |
| Rating | 4.9 out of 5 across 1,300+ ratings |
| Free preview | Yes, on DesignGurus.io |
Three things shape how it teaches.
Every pattern answers the same five questions. What problem does it solve, what does it cost, how does it fail, when is it wrong, and what does it combine with. The consistency is the point: after twenty lessons you start asking those questions yourself, of patterns the course has not taught you yet.
Real failures, not only the paths where things work. Each pattern comes with how it breaks in production: the retry storm that took down the payment processor, the cache stampede at midnight, the saga that half-completed. Failure reasoning is what senior interviews and real incident reviews both demand.
Every chapter ends in a capstone. After the communication chapter you design a notification system. After caching, you cache a product catalog properly. After resilience, you harden a payment flow. The capstone forces the chapter's patterns to work together. Four full system designs close the course: a news feed, ride-sharing dispatch, a payment platform, and an AI copilot.
Which course first, if you are also preparing for an interview
This is the most common question in my inbox, so here is the direct answer.
They are two layers of the same skill, not two versions of the same course.
Grokking the System Design Interview is the interview layer. It teaches you to run a 45-minute design conversation: a six-step framework, 15 classic problems worked end to end, 237 quizzes, and an AI design playground for practicing attempts. It is built around a clock and an interviewer.
System Design Patterns is the concept layer. It teaches the 62 patterns systems are actually built from, one lesson each, with what the pattern solves, what it costs, and how it fails in production. No clock, no interviewer, just fluency.
The interview course teaches you to structure an answer. The patterns course is why your answer survives the third follow-up question.
Where they overlap, honestly. Both cover the core building blocks: load balancing, caching, sharding, replication, queues. The difference is depth, angle, and coverage. The interview course teaches cache-aside well enough to use it in a design answer; the patterns course teaches all five caching strategies plus stampede prevention with the production failure stories. Roughly 70% of the patterns course has no equivalent in the interview course at all: coordination, operations, data processing, and the entire AI infrastructure chapter.
Call it 30% shared foundations and 70% distinct purpose. Enough overlap that you should not run both at once. Enough difference that they do not substitute for each other.
| Your situation | Take first | Then |
|---|---|---|
| Interview inside 8 weeks | Grokking the System Design Interview | Patterns chapters for weak spots only |
| No deadline, building durable skill | System Design Patterns | The interview course when a loop appears |
| Senior, staff, or L5 to L6 loop | Grokking the SDI plus Volume II | Patterns as a between-rounds reference |
| Data or AI engineer | System Design Patterns | The interview course only if the round exists |
| New to backend work | System Design Fundamentals | Then either, per the rows above |
Do you need both? Honestly, by group:
- Both: engineers who interview periodically and work on systems in between. The interview course for the loops, the patterns course for the years between them.
- Only the interview course: candidates with one loop ahead and no particular interest in going deeper afterwards. That is a legitimate way to use these courses.
- Only the patterns course: working engineers who are not interviewing and want the vocabulary and judgment for design reviews, incident calls, and architecture work.
- Neither yet: if you are still unsure what a database index or an API is, start with Fundamentals.
Frequently asked questions
What are system design patterns?
Reusable solutions to the recurring problems of building scalable systems: distributing traffic, splitting data, caching reads, absorbing spikes, surviving failures, and coordinating machines. Like design patterns in code, they are a shared vocabulary. Unlike them, they operate at the architecture level.
How many system design patterns are there?
There is no official registry, but the working vocabulary of modern systems comes to about 60. The list on this page covers 62 in 10 categories.
Which system design patterns are most important for interviews?
The twelve in Part 2: load balancing, caching, sharding, consistent hashing, primary-replica replication, message queues, publish-subscribe, 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 62 patterns for a system design interview?
No. Interview preparation should start with the twelve and go deep rather than wide. The full list matters more for working engineers, and for senior candidates closing blind spots.
Are these the same as Gang of Four design patterns such as singleton, factory, and observer?
No. Gang of Four patterns organize code within a program. System design patterns organize infrastructure across machines. Observer and publish-subscribe are conceptually related, but the failure modes, the tooling, and the interviews for each are entirely different.
How do interviewers actually test pattern knowledge?
Almost never by asking what a circuit breaker is. They pose a design, wait for you to reach for a pattern, then probe its mechanism and its cost: which algorithm, which failure mode, which trade-off. Naming patterns without mechanisms reads worse than not naming them.
What is the System Design Patterns course?
A course of roughly 20 hours teaching the 62 patterns across 10 chapters, from communication and caching through AI infrastructure, with a capstone design per chapter and four full system designs at the end. It lives on DesignGurus.io with free preview lessons.
Is the patterns course an interview preparation course?
It helps interviews substantially but it is not interview-shaped. It has no interview framework and no time-boxed practice. It builds the conceptual depth that makes your answers survive follow-up questions. For the interview loop itself, the flagship course is the tool.
Can the patterns course replace Grokking the System Design Interview?
Not on a deadline. For an actual loop, the interview course is the tool and the patterns course is the addition. Without a deadline, patterns first is the better foundation.
Do AI infrastructure patterns show up in interviews yet?
Increasingly, at AI-heavy companies: RAG pipelines, model serving, and semantic caching have started appearing in loops. For most general loops, the twelve in Part 2 still carry the round.
Where can I learn these patterns for free?
This page is the complete list. Beyond it, the GitHub companion repository and the interview guide on this site are free, and both courses have free preview lessons.
Related reading
- About Grokking the System Design Interview. The interview-focused course that applies these patterns to worked problems.
- Grokking's pattern courses, untangled. Coding patterns against system design patterns against microservices patterns.
- Grokking ML and AI system design. What exists today, and who publishes what.
- Every Grokking course explained. The full catalog map.
- How long does it take to prepare?. Study plans for two-week and six-week windows.
- The complete interview guide. The six-step framework these patterns plug into.
Go deeper than one-line definitions
Every pattern on this page is a full lesson in System Design Patterns: From Fundamentals to Real Systems: what it solves, what it costs, how it fails in production, and a capstone design per chapter that chains the patterns together. Free preview lessons are available before you commit to anything.
Explore System Design Patterns · Start free on Grokking the System Design Interview