A short disclosure: this reference mirrors the structure of System Design Patterns: From Fundamentals to Real Systems, the course I built, where each of these patterns is a full lesson. The cheat sheet below is free and complete on its own; the course is where each one-liner becomes an actual understanding, with real 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, every architecture diagram you see stops being a wall of boxes and becomes a sentence you can read.
This page is the full vocabulary: 62 patterns, organized into 10 categories, each with a one-line definition of what it does and when you'd reach for it. Bookmark it, and when a one-liner isn't enough, go deeper on that pattern specifically.
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 (WebSockets) for chat, collaboration, and games. |
2. Data and storage patterns
Where the data lives, how it's 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 can't hold or serve it all. |
| Consistent Hashing | Assigns data to shards so adding a node doesn't 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 on fire.
| Pattern | What it does |
|---|---|
| Cache-Aside | The app 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's 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 blip into a self-inflicted denial of service. |
| Idempotency | Makes retries safe, so "charged the card twice" can't 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 can't drown 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 box. Underrated up to a point, a dead end past it. |
| Horizontal Scaling | Add more boxes. 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 a lot of "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 front door 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 auth, routing, and throttling across services. |
| Backend for Frontend | A tailored API layer per client type instead of one generic one for all. |
| Rate Limiting | Token bucket and friends: protects the system from overuse, malicious or accidental. |
| Cursor-Based Pagination | Pagination that stays correct at scale, where offset pagination falls apart. |
| API Versioning | Evolves an API without breaking the clients already using it. |
| Sidecar | Bolts cross-cutting concerns onto a service without touching its code. |
| Service Mesh | Sidecars everywhere, managed centrally: traffic control between all services. |
8. Operations and delivery patterns
Shipping and running systems without 3 a.m. surprises.
| Pattern | What it does |
|---|---|
| Health Check Endpoint | Lets infrastructure ask "are you okay?" and act on the answer. |
| Distributed Tracing | Follows one request across a dozen services to find the slow hop. |
| Blue-Green Deployment | Two environments, instant switch, instant rollback. |
| Canary Deployment | Releases to 1% first and lets the metrics decide the rest. |
| Feature Flags | Decouples 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 buried. |
| Partitioned Consumption | Parallelizes a stream while keeping per-key ordering. |
10. AI infrastructure patterns
The newest chapter of the vocabulary, and the one interviews are adding fastest.
| Pattern | What it does |
|---|---|
| Feature Store | One consistent source of ML 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 burning money on idle. |
| LLM Gateway | One control point for model routing, cost caps, and fallbacks. |
| Semantic Caching | Caches LLM answers by meaning, not exact string match. |
| Vector Database Sharding | Scales similarity search past one machine. |
| RAG Pipeline | Retrieval plus generation: grounds model answers in your own data. |
How to actually use this list
A cheat sheet tells you the words exist. Three suggestions for turning the words into ability:
Don't memorize down the list; connect across it. Real designs chain patterns: a notification system is pub-sub plus a message queue plus idempotency plus rate limiting. When you study one pattern, ask which others it usually travels with. That connective tissue is what the capstone design at the end of each course chapter drills: one realistic system per chapter, assembled from the patterns you just learned.
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 can't argue against is a pattern you don't understand yet, and interviewers know this trick too.
If you're preparing for interviews, prioritize. You don't need all 62 for a system design round. The dozen that carry most interviews are covered in the 12 patterns that decide most interviews, with the exact probing question each one answers.
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're a shared vocabulary; unlike them, they operate at the architecture level.
How many system design patterns are there? There's no official registry, but the working vocabulary of modern systems comes to about 60. The list above covers 62, organized into 10 categories, matching the structure of the System Design Patterns course.
Are these the same as GoF design patterns (singleton, factory, observer)? No. Gang of Four patterns organize code within a program. System design patterns organize infrastructure across machines. Observer and publish-subscribe are conceptual cousins, but the failure modes, tooling, and interviews for each are entirely different.
Do I need to know all of these for a system design interview? No. Interviews concentrate on a much smaller set; see the 12 that decide most interviews. The full list matters more for working engineers, and for senior candidates who want no blind spots.
Where can I learn these patterns in depth? Each pattern above is a full lesson in System Design Patterns: From Fundamentals to Real Systems, taught with real failure stories and capstone designs. For interview-specific preparation, Grokking the System Design Interview applies the core patterns to 18 worked interview problems. Free options: the GitHub companion repo and the interview guide on this site.
Related reading
- The 12 System Design Patterns That Decide Most Interviews. The prioritized subset, with the interview moment each one wins.
- About Grokking the System Design Interview. The interview-focused course that applies these patterns to worked problems.
- What's New in Grokking System Design in 2026. How the course family has evolved.
- The Complete Interview Guide. The 6-step framework these patterns plug into.
Go deeper than one-liners
Every pattern on this page is a 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 on DesignGurus.io · The 12 Interview-Critical Patterns