System Design Patterns: The Complete Guide (60+ Patterns Explained Simply)

Every system you admire is built from parts you can name. The feed that loads in 80 milliseconds, the checkout that survives a datacenter failure, the chatbot that answers from yesterday's documentation: each one is a composition of the same recurring solutions, applied in the right places. Those recurring solutions are system design patterns, and there are roughly sixty of them worth knowing.

This guide covers all of them. For each pattern you will get three things: the problem it solves, the core move it makes, and the price you pay for using it. By the end, you should be able to look at any architecture, or any interview prompt, and see the parts.

1. What Are System Design Patterns?

A system design pattern is a named, reusable solution to a problem that recurs when you build distributed systems. "Reads are overwhelming my database" is a recurring problem; primary-replica replication is its named solution. "A retry charged the customer twice" is a recurring problem; idempotency is its named solution.

Two clarifications before we start.

First, system design patterns are not the same as the classic "design patterns" from the Gang of Four book. Those are code-level patterns (Singleton, Observer, Factory) for organizing classes inside one program. System design patterns are architecture-level: they describe how databases, queues, caches, and services work together across many machines. In a system design interview, the interviewer means the architecture-level kind.

Second, a pattern is not a technology. Kafka is a product; the message queue and the append-only log are the patterns inside it. Redis is a product; cache-aside is the pattern you use it for. Learn the pattern and you can evaluate any product. Learn only the product and you are lost when the stack changes.

2. Why Patterns Beat Memorizing Architectures

There are thousands of possible system designs, and you cannot memorize them all. You do not need to. Architectures are sentences; patterns are the words. Once you own the vocabulary, "design Instagram" stops being a memory test and becomes a composition exercise.

Working with patterns is three habits:

1. Diagnosis. Recognize which problem you are actually looking at. Dashboards are green but one feature is starving: that is the bulkhead problem. Two teams' metrics disagree: that is the same question with two authors. Most of system design skill is matching symptoms to shapes.
2. Composition. Combine patterns, and handle the seams between them. Retries demand idempotency. Caches demand a stampede plan. Sagas demand designed compensations. The seams are where real engineering lives.
3. Pricing. Every pattern is a purchase. Sharding buys write scale and costs you cross-shard queries. Caching buys speed and costs you staleness. Saying the cost out loud, in the same breath as the pattern, is what separates senior answers from buzzword answers.

Keep those three habits in mind as you read the catalog below. Each entry is deliberately structured as diagnosis (the problem), composition material (the move), and price (the cost).

(I teach all sixty of these patterns in depth, each one through a real production incident, in my course System Design Patterns: From Fundamentals to Real Systems. This guide is the map; the course is the territory.)

3. The Complete List: 60+ System Design Patterns by Category

The patterns fall into ten categories. Use the list below to jump around, or read straight through: the order follows how problems actually arrive as a system grows.

1. Communication patterns (7)
2. Storage and replication patterns (6)
3. Caching patterns (5)
4. Reliability patterns (7)
5. Scaling patterns (5)
6. Consistency patterns (4)
7. API and edge patterns (9)
8. Operations and delivery patterns (5)
9. Data-intensive patterns (7)
10. AI-era patterns (7)

Communication Patterns: Moving Data Between Services

Request-Response. The default: a client asks, a server answers, someone waits. It is the right choice whenever a user is waiting for the answer. Its weakness is coupling: the caller's fate is tied to the callee's speed and health, which is why half the reliability patterns below exist.

Message Queue. Work that nobody needs to wait on goes into a queue, and workers process it at their own pace. Traffic spikes become backlog instead of outages. The price: delivery is at-least-once, so consumers must handle duplicates, and the queue's depth becomes a metric you must watch.

Publish-Subscribe. One event, many independent consumers. The order service announces "order placed" once; email, analytics, and inventory each react without knowing about each other. The price: your event schema becomes a public contract, and changing it becomes a negotiation.

Event-Driven Architecture. The pub-sub idea promoted to an architectural style: services react to facts instead of calling each other. You gain loose coupling and independent scaling. You pay in governance: who consumes what, and how a business flow is traced across five reacting services.

Webhooks. Events delivered across company boundaries as HTTP POSTs. The receiving discipline: verify the signature, save the raw event, respond in milliseconds, process later behind your own queue, and reconcile with a polling loop, because the worst webhook failure looks exactly like a quiet day.

Server-Sent Events (SSE). One HTTP response that never ends: the server pushes updates down it as they happen. It is why LLM chat apps show words one at a time. One direction only, and the browser handles reconnection for you. When the client needs to talk back continuously, you have outgrown it.

Bidirectional Streaming (WebSockets). A true two-way conversation on one connection: chat, collaborative editing, multiplayer games. The price is stateful, sticky connections and reconnection logic you now own. The rule: escalate to it on need, never on fashion.

Storage and Replication Patterns: Where Truth Lives

Primary-Replica Replication. One machine takes all writes and streams its change log to replicas that serve reads. Read capacity scales by adding copies, and a dead primary is replaced by promoting a replica. The price: replicas lag slightly, so a user can miss their own write, and replicas add zero write capacity.

Sharding. When writes or data size outgrow one machine, split the table's rows across machines by a shard key. The key is the whole game: it should appear in nearly every query, spread load evenly, and keep related rows together. The price: cross-shard queries, cross-shard transactions, and hot keys become your problems.

Consistent Hashing. The routing rule that lets a cluster change size gracefully. With naive modulo routing, adding a fifth shard moves 80% of all data. On the hash ring, it moves about 20%: only the slice the new server takes over. Virtual nodes keep the slices even and spread a dead server's load across everyone.

Write-Ahead Log (WAL). Before touching any data structure, the database appends one record describing the change to a log and forces it to disk. Only then does it say "saved." Crash recovery is replaying the log. This one mechanism also powers replication and point-in-time recovery, which makes the append-only log the most important structure in the database.

Event Sourcing. Store what happened, not what is. Every change is an immutable business event (OrderPlaced, OrderCancelled), and current state is derived by replaying them. Perfect audit trails and time travel, at the cost of projections for queries and event schemas that live forever. The default answer is no; the exception is ledger-shaped domains: money, orders, inventory.

CQRS. When reads and writes want different shapes, split the model: a lean, validated write model, and read models shaped for each question (a pre-joined table, a search index, an aggregates store), kept in sync from a change stream. Never sync them by writing to both from application code: dual writes drift silently.

Caching Patterns: Serving Data Fast

Cache-Aside. The default cache: the application checks the cache, loads from the database on a miss, and stores the result. Two numbers rule everything: the hit ratio and the staleness budget. Invalidation is your job, and the TTL is your safety net.

Read-Through. The cache itself loads misses from the database, so application code just reads. Cleaner call sites, at the cost of a smarter cache layer in your read path.

Write-Through. Writes go to the cache and the store together, so reads are always warm and never stale. The price: every write pays for both.

Write-Behind. Writes land in the cache and flush to the store later, in batches. Enormous write throughput, with a window where acknowledged data exists only in memory. Never for money.

Cache Stampede Prevention. When a popular key expires, a thousand requests can miss at once and crush the database together. The cures: let one request rebuild while others wait (single flight), add jitter to expiry times, and refresh hot keys before they expire.

Reliability Patterns: Surviving Failure

Timeout. No wait is allowed to be unbounded. Every network call gets a deadline, chosen from the callee's real latency profile. The subtlety: a timeout means "I stopped waiting," never "it did not happen." The work may have finished after you gave up, which is why idempotency exists.

Retry with Exponential Backoff. Transient failures deserve a second try, with increasing delays and randomness (jitter) so a thousand clients do not retry in lockstep and finish off a struggling server. Retries without backoff, jitter, and a budget are how outages get worse.

Idempotency. The same request processed twice must have the effect of once. The client generates a unique key per operation, and the server remembers keys it has seen. This is the pattern that makes retries safe, and the reason a double-clicked "Pay" button charges once.

Circuit Breaker. When a dependency keeps failing, stop calling it. Fail fast, give it time to recover, and probe occasionally to see if it is back. This turns a slow, cascading failure into a fast, contained one.

Bulkhead. Partition your resources so one workload cannot starve the rest. Separate connection pools, thread pools, or fleets per feature. The symptom it prevents: dashboards green overall while one feature quietly consumed every thread.

Dead Letter Queue. A message that fails repeatedly gets moved aside into a quarantine queue, so it stops blocking everything behind it. The DLQ needs an owner and an alert, or it becomes a place where problems go to be forgotten.

Graceful Degradation. Decide in advance what each feature does when its dependencies fail: serve stale data, show a smaller answer, or refuse. Availability features fail open; money and authorization fail closed. The worst answer is the one nobody designed: a blank error page.

Scaling Patterns: Growing Under Load

Vertical Scaling. A bigger machine. No new failure modes, no code changes, and it buys you time. It has a ceiling, and at the top of the catalog the prices climb steeply. Exhaust the simple win before taking on distributed problems.

Horizontal Scaling. Many identical, stateless copies behind a load balancer. The catch is the word stateless: sessions, counters, and files must move out of the server first, or each copy holds a different fraction of the truth.

Load Balancing. Spreading requests across those copies, informed by health checks and actual load. Draining connections before removing a server is the difference between a deploy and an incident.

Auto-Scaling. Capacity that follows demand: scheduled scaling for the load you can predict (most of it), reactive scaling for the surprise. Reaction takes minutes, so headroom is part of the design, and the maximum is a safety limit you set on purpose.

Connection Pooling. Opening a database connection is expensive; reuse a small pool of warm ones instead. The quiet trap: pool size multiplies across your fleet, and 50 servers with modest pools can exhaust a database's connection limit.

Consistency Patterns: Keeping Data Correct Across Machines

Two-Phase Commit (2PC). The coordinator asks all participants to prepare, then tells them all to commit: atomicity across machines. The price: everyone blocks if the coordinator dies at the wrong moment. It works inside one trust boundary; it does not cross companies. Often the best move is designing the transaction away entirely.

Saga. A long business transaction as a sequence of local steps, each with a designed compensation (undo) if a later step fails. Book the flight, book the hotel; if the hotel fails, unbook the flight. Order the irreversible steps last. This is how money moves between systems that share no database.

Quorum. Decisions by majority: with three or five copies, require agreement from more than half before an answer counts. Majorities prevent split brain, because two disagreeing majorities cannot exist. The price is latency, and a minority partition that goes read-only on purpose.

Vector Clocks. A way to track causality so the system can tell "this edit came after that one" apart from "these two edits happened concurrently and neither saw the other." Concurrent edits become explicit conflicts to resolve rather than silent overwrites.

API and Edge Patterns: The Front Door

Reverse Proxy. One front door for your servers: it terminates TLS, routes requests, and shields the fleet behind it. Nearly every pattern in this category is a specialized reverse proxy.

CDN. Copies of your content cached at the edge, near users. The two disciplines: getting invalidation right, and never letting private, per-user responses into a shared cache.

API Gateway. Cross-cutting policy enforced once: authentication, rate limits, routing to services. The discipline is staying thin. The moment business logic moves in, you have rebuilt the monolith in the doorway.

Backend for Frontend (BFF). A thin backend per client type (web, mobile) that composes reads into exactly the shape that client needs. Presentation composes reads; the domain services keep owning writes.

Rate Limiting. Protecting capacity by refusing excess politely: token buckets that allow bursts but cap sustained rates, tiered by customer. A 429 with a Retry-After header is a feature, not a failure.

Cursor-Based Pagination. Page through data by position ("after item X") instead of offset ("items 51-100"), so results stay stable while new data arrives. The price: no jumping to page seven.

API Versioning. Changing an API without breaking its clients: additive changes where possible, versioned contracts where not. Every field you publish is a promise someone will hold you to for years.

Sidecar. Cross-cutting concerns (TLS, retries, telemetry) packaged as a helper process that runs beside every service instance, in any language. The building block that makes the next pattern possible.

Service Mesh. Sidecars on every service plus a control plane: mutual TLS, retries, timeouts, and telemetry for all service-to-service traffic, without touching application code. A heavy platform. Adopt it when the service count and compliance needs clear the bar, not before.

Operations and Delivery Patterns: Shipping Without Breaking

Health Check Endpoint. The difference between "the process is running" (liveness) and "the process can do useful work" (readiness), exposed as endpoints that load balancers and deploys consult. Shallow checks lie; check the dependencies that matter.

Distributed Tracing. One request's story across every service it touched, stitched together by a trace ID. When the checkout is slow, the trace shows which of the nine hops ate the time. Instrumentation costs effort; debugging without it costs more.

Blue-Green Deployment. Two identical environments; switch traffic instantly, switch back instantly if something breaks. The catch everyone learns once: the database does not blue-green. Schema changes need the expand-contract discipline.

Canary Deployment. Release to a small slice first, judge it against the current version on real metrics, then widen. The judging is the pattern: a canary without honest verdict metrics is theater.

Feature Flags. Separate deploying code from releasing behavior. The code ships dark; the behavior turns on with a flag, per cohort, reversible in seconds. The debt: flags must be deleted after they win, or the codebase fills with dead switches.

Data-Intensive Patterns: Batch and Streaming

MapReduce. The batch shape: process a huge dataset by working on pieces in parallel where the data lives (map), regrouping by key (shuffle), and merging (reduce). You will never write raw MapReduce, and you will never escape its shape: it is the physics under every warehouse and Spark job.

Stream Processing. A job that runs forever, holding running counts keyed by the thing being watched, answering while the data is still arriving. Its hard ideas: event time versus arrival time, watermarks that decide when a window may close, and answers that may be amended when stragglers arrive.

Lambda and Kappa Architectures. Two answers to batch and streaming both computing the same numbers. Lambda runs both, with batch overwriting the stream's results on schedule. Kappa keeps one streaming codebase over a replayable log and re-runs history when logic changes. The rule either way: every metric gets exactly one definition of truth.

Change Data Capture (CDC). Tail the database's own write-ahead log and publish every committed change as an event. It cannot miss: bulk imports and manual fixes flow through the same log as app writes. This is how search indexes, caches, and warehouses stay in sync without fragile dual writes.

Exactly-Once Semantics. Counting things once despite crashes and retries. Delivery can never be exactly-once; the effect can be, by moving the processing state and the outputs together with the log position. Reserve the heavy machinery for numbers with auditors: billing, ledgers.

Backpressure. When a producer outruns a consumer, something must give: a bounded buffer absorbs bursts, a drop policy sheds what is worthless when stale, or the producer is slowed. The one wrong answer is the unbounded buffer, which schedules an out-of-memory crash instead of surfacing the mismatch.

Partitioned Consumption. Order per key, parallelism across keys: every event for a given customer lands in the same partition, each partition has exactly one consumer, so a refund can never be processed before its charge. The partition count is a ceiling chosen in advance, and one hot key can still make one partition burn.

AI-Era Patterns: LLM and ML Infrastructure

Nothing in the AI stack is architecturally new; every pattern here is one of the above operating under changed constants. But the changed constants matter enough that these seven deserve their own names.

Feature Store. Define each ML feature once, and let a platform compute it both offline for training and online for serving. This kills training/serving skew: the silent bug where a model learns from one definition of a number and gets served another.

Model Serving and Batching. At batch-of-one, a GPU serving an LLM runs at single-digit utilization, because each token step streams the whole model's weights to do almost no math. Continuous batching lets dozens of requests share each weight-pass, multiplying throughput 20-30x. It is the difference between a viable AI feature and an absurd bill.

GPU Auto-Scaling. Web autoscaling with both dials at 100x: idle GPUs cost a hundred times more, and cold starts take minutes, not seconds. The answers: scale on queue depth (never CPU), keep warm pools as priced insurance, pre-warm on the calendar, and fall back to a smaller model when capacity gaps hit.

LLM Gateway. One internal door for all model traffic: it holds the provider keys, meters every token against budgets with hard caps, routes logical model names to physical providers, and runs the failover ladder when a provider browns out. The API gateway pattern, pointed outward.

Semantic Caching. Forty percent of user questions are rephrasings of known questions, but exact-match caching catches almost none of them. Key the cache by meaning instead: embed the query and match by similarity, with a conservative threshold, because a false hit serves a confidently wrong answer.

Vector Database Sharding. Similarity search breaks normal sharding's best rule: a nearest-neighbor query has no shard key, so the default is asking every shard and merging. The escape: when every query is tenant-scoped, the tenant filter becomes the shard key and single-shard routing returns.

RAG Pipeline. Knowledge in model weights has no update path, no citations, and no access control. Retrieval-Augmented Generation fixes all three: keep documents in an index that updates in seconds, retrieve only what the asker is permitted to read, and require the model to answer from the retrieved text with citations. The model reasons; the index remembers.

4. How Patterns Compose: A News Feed in Ten Patterns

A pattern list becomes useful when you see composition. Take the classic prompt: design a social feed. Watch the patterns snap together.

Reads outnumber writes about 50 to 1, so the feed is a read-serving problem. Precompute each user's feed at write time and serve it like a cache: this is CQRS, with the feed as a read model. Posting fans out through a message queue with partitioned consumption, fed reliably by an outbox (CDC) so a committed post always reaches the pipeline. The feed store is a sharded, consistent-hashed cluster of lists, evicted and rebuilt like any cache. Celebrities with 50 million followers would break write-time fan-out, so their posts merge at read time from a hot cache with stampede prevention. Fan-out workers auto-scale on backlog age. Appends are idempotent so at-least-once delivery cannot duplicate a post. When parts fail, the feed degrades gracefully: slightly stale beats blank.

Ten-plus patterns, one design, and every choice justified by a number or a failure mode. That is what interviewers mean when they say a candidate "thinks in systems." It is also the skill this entire catalog exists to build: not knowing sixty definitions, but composing the right eight of them under pressure.

5. How to Learn These Patterns Properly

Reading a list is recognition. Interviews and production require recall and application. Three suggestions:

1. Learn each pattern through its failure story. Every pattern above exists because something broke at 2 AM. "Cache stampede prevention" is forgettable; "a thousand requests missed the same expired key at once and crushed the database" is not. Attach each pattern to its incident.
2. Always learn the price and the "when not." A pattern you cannot argue against is a pattern you do not understand. Sharding from day one, CQRS on a settings page, and event sourcing everywhere are the classic ways to pay real complexity for imaginary scale.
3. Practice composition on full designs. Run the classic prompts (a feed, a ride-sharing dispatch, a payment platform) and force yourself to name every pattern you use and what it costs, out loud.

This is exactly how my course, System Design Patterns: From Fundamentals to Real Systems, is built. All sixty-plus patterns above get a full lesson: a real production incident, the naive fixes and why they fail, a walkthrough with real numbers, the trade-offs, when NOT to use it, and a 30-second interview answer you can say under pressure. The course ends with four complete interview walkthroughs (a news feed, ride-sharing dispatch, a payment platform, and an AI copilot) where you watch the sixty patterns compose into real systems.

6. Frequently Asked Questions

What are system design patterns? System design patterns are named, reusable solutions to problems that recur in distributed systems: scaling reads, surviving failures, keeping data consistent across machines, and moving data between services. They are architecture-level building blocks, used to design systems like feeds, payment platforms, and chat applications.

How many system design patterns are there? Around sixty patterns cover essentially everything asked in interviews and used in production, spanning communication, storage, caching, reliability, scaling, consistency, APIs, operations, data engineering, and AI infrastructure. This guide lists all of them by category.

Are system design patterns the same as design patterns? No. Classic design patterns (from the Gang of Four book) organize code inside one program: Singleton, Observer, Factory. System design patterns organize infrastructure across many machines: sharding, caching, circuit breakers, sagas. In system design interviews, the interviewer means the architecture-level kind.

Which system design patterns matter most for interviews? Eight patterns appear in the overwhelming majority of interview questions: cache-aside, sharding, message queues, circuit breakers, idempotency, sagas, CQRS, and rate limiting. Learn those deeply first, then broaden. The highest-scoring skill is not naming patterns but stating each one's cost as you use it.

Do AI systems need new system design patterns? Mostly no, and that is good news. The LLM gateway is the API gateway pattern pointed outward, semantic caching is cache-aside with similarity instead of equality, and GPU autoscaling is standard autoscaling with far harsher constants. An engineer who knows the classic sixty walks into AI infrastructure already knowing the building.

---

Arslan Ahmad is the author of Grokking the System Design Interview and founder of DesignGurus.io. His new course, System Design Patterns: From Fundamentals to Real Systems, teaches all sixty-plus patterns in this guide through real production incidents.