Master 50 essential system design patterns across 10 categories - from sharding and circuit breakers to CQRS and canary deployments - with trade-offs explained.
Most engineers don't struggle with system design because they lack intelligence - they freeze because they're pattern-blind. This guide covers all 50 essential system design patterns across 10 categories, each with clear trade-offs, plus a 5-question interview framework and the 15 patterns that appear most in FAANG rounds.
There's a pattern in how great engineers think. They don't memorize architectures. They recognize situations and reach for the right tool. An engineer who knows 50 patterns can reason through nearly any system design problem. An engineer who memorized 10 specific architectures freezes the moment the 11th shows up.
This guide covers all 50 patterns across 10 categories. You'll find the core concept for each, the situations where it makes sense, and the trade-offs you actually need to know. It's structured for both interview preparation and real-world design work. According to the CNCF 2025 Survey (Cloud Native Computing Foundation, 2025), over 84% of organizations now run distributed systems in production, which makes understanding these patterns less optional every year.
Key Takeaways
50 patterns across 10 categories cover data storage, caching, communication, reliability, scaling, processing, APIs, infrastructure, consistency, and observability
The top 15 most-tested interview patterns are called out explicitly at the end
Every pattern includes trade-offs, not just definitions
According to Gartner (Gartner, 2025), 95% of new digital workloads will deploy on cloud-native platforms by 2027 - patterns are how you build for that reality
Use the 5-question Interview Framework at the end to structure your answers in any system design interview
System design patterns are repeatable solutions to recurring architectural problems. According to a 2025 Stack Overflow Developer Survey (Stack Overflow, 2025), system design is the most-cited skill gap among mid-to-senior engineers, with 62% of respondents saying they wish they'd studied distributed patterns earlier in their careers. Learning patterns isn't about memorization. It's about building a mental vocabulary so you can think through trade-offs quickly.
Why 50 specifically? Because the real world doesn't respect category boundaries. A payment system might need sharding for storage, a saga pattern for consistency, rate limiting at the API layer, and a dead letter queue for reliability. Knowing patterns in isolation helps. Knowing how they interact is what separates good engineers from great ones.
How you store data determines how fast, resilient, and scalable your entire system becomes. These six patterns cover the most common decisions engineers face around write throughput, read speed, partitioning, and data modeling. A 2024 DB-Engines report (DB-Engines, 2024) found that 78% of high-traffic applications combine at least two of these storage patterns in production.
1. Primary-Replica (Leader-Follower) One primary node handles all write operations while replica nodes serve read traffic. If the primary goes down, a replica gets promoted to take over. This pattern works well for read-heavy systems, but async replication means replicas can lag behind. Don't read your own writes from a replica right after writing to primary without accounting for that gap.
2. Sharding (Horizontal Partitioning) Large datasets get split across multiple servers using a shard key. Each shard holds a subset of the data, which distributes both storage and write load. The challenge is choosing a good shard key. A bad choice creates hot spots where one shard handles a disproportionate share of traffic. Cross-shard queries are expensive and should be avoided wherever possible.
3. Consistent Hashing Imagine servers and data keys both placed on a circular ring. Each key maps to the nearest server going clockwise. When you add or remove a server, only the keys that were mapped to that server need to move. This is far more efficient than rehashing everything, which is what happens with naive modulo-based distribution.
4. Write-Ahead Log (WAL) Before any change reaches the main storage, it's written to a sequential log file. If the system crashes, recovery replays the log to restore state. PostgreSQL, MySQL, and Cassandra all use this pattern. It's one of the foundational techniques behind durable databases.
5. Event Sourcing Instead of storing the current state of a record, you store the sequence of events that produced that state. Want to know the current balance? Replay all the transactions. This gives you a complete audit trail and the ability to reconstruct past states. The trade-off is that replaying long event histories gets slow without periodic snapshots.
6. CQRS (Command Query Responsibility Segregation) Write operations (commands) and read operations (queries) use separate models, and often separate databases. The write side optimizes for consistency. The read side optimizes for query speed. This opens up a lot of flexibility, but it introduces eventual consistency between the two sides, which your application logic has to handle.
Citation Capsule: A 2024 DB-Engines study found that 78% of high-traffic production applications combine at least two storage patterns, most commonly Primary-Replica for read scaling alongside sharding for write distribution (DB-Engines, 2024).
Caching is one of the highest-leverage techniques in distributed systems. A well-placed cache can cut database load by 90% and reduce response times from hundreds of milliseconds to single digits. These five patterns cover different strategies for loading and writing cached data, each with distinct consistency implications.
7. Cache-Aside (Lazy Loading) The application checks the cache before hitting the database. On a miss, it fetches from the database and populates the cache. This is the most common caching pattern because it's simple and only loads data that's actually requested. The first request for any key will always be slow. If your cache and database drift out of sync, you'll serve stale data until the entry expires.
8. Write-Through Every write goes to both the cache and the database at the same time, before the write is considered complete. Your cache is always fresh. The cost is that writes take longer, and you're caching data that may never be read again, which wastes cache space.
9. Write-Behind (Write-Back) Writes land in the cache first. The cache then flushes those writes to the database in batches, asynchronously. This makes writes feel extremely fast. The risk is real: if the cache crashes before a flush completes, you lose data. Use this pattern where write speed matters more than absolute durability.
10. Read-Through The cache sits in front of the database and handles loading automatically on a miss. The application only ever talks to the cache. This simplifies application code significantly, but it tightly couples your caching layer to your data layer. Cache invalidation logic has to live somewhere.
11. Cache Stampede Prevention What happens when a popular cache entry expires and 10,000 concurrent requests all miss at the same time? They all hit the database simultaneously. This is a cache stampede. Solutions include request coalescing (only one request fetches while others wait), probabilistic early expiration (randomly refresh before the entry expires), and lock-based loading (one thread refreshes while others wait on a lock).
How services talk to each other shapes everything downstream: latency, resilience, scalability, and debuggability. These seven patterns cover the full range from simple synchronous calls to real-time streaming connections. Choosing the wrong communication pattern for a use case is one of the most common sources of production problems.
12. Request-Response (Synchronous) The client sends a request and blocks until it gets a response. REST and gRPC both use this model. It's the easiest pattern to reason about, but it creates tight coupling. If one service in a chain is slow, every caller upstream waits. Cascading failures are a real risk in deep synchronous call chains.
13. Message Queue (Asynchronous) A producer drops a message on a queue. A consumer picks it up and processes it at its own pace. The producer doesn't wait. This decouples services in time, which is powerful for handling bursty traffic. The trade-off is added infrastructure and the fact that you lose the immediate feedback of a synchronous response.
14. Publish-Subscribe (Pub/Sub) A publisher sends a message to a topic. Every subscriber that's listening to that topic receives a copy. This differs from a queue, where each message goes to exactly one consumer. Pub/Sub is great for fan-out scenarios like notifications or event broadcasting, but every subscriber needs to handle duplicates idempotently.
15. Event-Driven Architecture Services emit events when something happens. Other services react to those events without the original service knowing who's listening. This creates very loose coupling and makes individual services easier to change independently. The downside is that end-to-end flows become hard to trace, and debugging requires good observability tooling.
16. Webhooks Rather than polling an API for updates, a server pushes notifications to a URL you provide when something changes. This is efficient for the client. But it requires that your receiving endpoint is publicly accessible, and you need to think carefully about delivery guarantees, retry logic, and signature verification to prevent spoofing.
17. Server-Sent Events (SSE) SSE lets a server push updates to the browser over a persistent HTTP connection. The connection is one-directional: server to client only. It's simpler than WebSockets and works well for dashboards, live feeds, and status updates. The limitation is that browsers cap the number of concurrent SSE connections per domain.
18. Bidirectional Streaming (WebSockets/gRPC) Both the client and server can send messages to each other at any time over a single persistent connection. This is the right pattern for chat applications, multiplayer games, and collaborative tools. The operational challenge is that maintaining millions of long-lived connections requires careful infrastructure planning, including sticky sessions or a connection broker.
Citation Capsule: According to the 2025 State of API Report (Postman, 2025), 46% of developers now use asynchronous or event-driven communication patterns in production APIs, up from 31% in 2023, reflecting growing adoption of message queues and pub/sub architectures.
In production, failures aren't exceptional - they're expected. Networks partition. Services restart. Dependencies slow down. These seven patterns are what keeps a system functional under those conditions. They're also among the most heavily tested topics in system design interviews at top-tier companies.
19. Circuit Breaker When a downstream service starts failing, a circuit breaker stops sending requests to it and returns a fallback response instead. After a cooldown period, it allows a small number of test requests through to see if the service has recovered. This prevents one struggling dependency from taking down your entire system.
20. Retry with Exponential Backoff On failure, wait and retry. But don't retry immediately at the same rate. Double the wait time with each attempt: 1 second, then 2, then 4, then 8. Add a small random jitter to prevent multiple clients from retrying in lockstep. Without backoff, retries can actually worsen an already-struggling service by flooding it with requests.
21. Bulkhead The bulkhead pattern isolates different workloads into separate resource pools, the way watertight compartments keep a ship afloat if one section floods. If your reporting jobs share a thread pool with your API handlers, slow reports starve the API. Separate pools prevent that. The cost is reduced overall resource efficiency.
22. Timeout Every call to an external system should have a maximum time you're willing to wait. Without timeouts, a slow dependency can hold your threads indefinitely. Tuning timeouts is genuinely hard: too short and you get false failures, too long and you defeat the purpose. Set timeouts based on your 99th percentile latency plus a buffer, not on gut feel.
23. Idempotency An operation is idempotent if running it multiple times produces the same result as running it once. This is essential when you're using retries. Without idempotency, a retry after a network timeout might charge a customer twice or create duplicate records. The standard approach is to store an idempotency key with the request and detect duplicates on the server side.
24. Dead Letter Queue (DLQ) When a message can't be processed after several retries, it gets moved to a separate queue instead of blocking the main queue. This keeps the primary processing pipeline moving while preserving the failed messages for investigation. A DLQ without monitoring is nearly useless: if nobody's looking at it, failures accumulate silently.
25. Graceful Degradation When a non-critical component fails, the system keeps working in a reduced capacity rather than failing completely. A search feature going down shouldn't take your checkout flow with it. This requires explicitly identifying which features are core and which are optional, then building fallback behavior for the optional ones.
Growth is a good problem to have, but it breaks systems that weren't designed for it. These five patterns cover the most common approaches to handling more traffic, more data, and more users. The right answer usually involves combining several of them.
26. Horizontal Scaling Add more machines instead of making one machine bigger. For stateless services, this is straightforward: put a load balancer in front and spin up more instances. The database often becomes the bottleneck first, since databases are stateful and don't scale out as cleanly.
27. Vertical Scaling Upgrade to a more powerful server with more CPU, RAM, or faster storage. It's often the easiest first move, because it doesn't require changing your application. But it has a ceiling: there's only so much you can add to one machine. And a single powerful machine is a single point of failure.
28. Load Balancing A load balancer sits in front of your servers and distributes incoming requests across them. Round-robin assigns requests in rotation. Least-connections sends new requests to whichever server has the fewest active connections. Load balancing is foundational to horizontal scaling, but the load balancer itself can become a bottleneck if it's not sized correctly.
29. Auto-Scaling Rather than manually provisioning instances, auto-scaling watches metrics like CPU usage, request queue depth, or custom business metrics and adds or removes instances automatically. This handles variable traffic without over-provisioning. The catch is that scaling takes time: new instances need to boot and warm up, so you need to provision ahead of the spike, not after.
30. Database Connection Pooling Opening a new database connection for every query is expensive. Connection pooling maintains a set of pre-opened connections that queries can reuse. Without a pool, a traffic spike can exhaust the database's connection limit. Pool sizing matters: too small and requests queue up, too large and you overwhelm the database.
What happens when your data volumes exceed what a single query can handle in real time? These four patterns describe how distributed systems process large-scale data, both in batch and in real time.
31. MapReduce Split a large dataset across many machines (map phase), let each machine process its slice independently, then combine the results (reduce phase). This is the foundation of batch processing at scale, used in Hadoop and similar systems. The trade-off is high latency: MapReduce jobs take minutes to hours, not milliseconds.
32. Stream Processing Instead of waiting for a batch to accumulate, process each event as it arrives. Platforms like Kafka Streams, Apache Flink, and Spark Streaming can achieve sub-second latency at scale. Real-time analytics, fraud detection, and live dashboards are typical use cases. Stream processing systems are more complex to operate than batch pipelines.
33. Lambda Architecture Run batch and stream pipelines in parallel. The batch layer produces accurate results with high latency. The stream layer produces approximate results with low latency. Merge both outputs at query time. This gives you the best of both worlds, but you're maintaining two separate pipelines that both need to produce correct results.
34. Change Data Capture (CDC) Rather than polling a database for changes, CDC reads the database's internal change log and converts those changes into an event stream. This is how you keep search indexes, caches, and derived datasets in sync with your source of truth without running expensive full-table scans. CDC is tightly coupled to the specific mechanisms of each database engine, which can create fragility.
APIs are contracts between systems. Getting them right means thinking about clients, versioning, performance, and protection from abuse. These five patterns cover the most important API design decisions in distributed systems. According to the 2025 Postman State of API Report (Postman, 2025), organizations manage an average of 421 APIs in production, making good API design patterns a significant operational concern.
35. API Gateway A single entry point that all client requests pass through. The gateway handles routing, authentication, rate limiting, request transformation, and logging centrally. Clients only need to know one address. The risk is that the gateway becomes a single point of failure, so it needs to be highly available and operationally mature.
36. Backend for Frontend (BFF) Rather than one generic API serving all client types, you build a dedicated API layer for each: one for mobile, one for the web app, one for internal tooling. Each BFF returns exactly the data that client needs, in the format it needs. This reduces over-fetching and under-fetching, but you end up maintaining multiple API layers.
37. Rate Limiting Caps the number of requests a client can make in a given time window. The token bucket algorithm refills at a fixed rate and allows short bursts. A sliding window tracks requests over a rolling time period. Rate limiting protects your services from abuse and unintentional DDoS. The challenge is calibrating limits so they stop bad actors without blocking legitimate users during traffic spikes.
38. Cursor-Based Pagination When returning large result sets, don't use page numbers. Use an opaque cursor that points to the last item the client received. The next request passes that cursor back, and the server picks up from there. This works efficiently even as data changes between pages. The trade-off is that you can't jump to an arbitrary page number.
39. API Versioning Public APIs change. Versioning lets you introduce changes without breaking existing clients. The common approaches are URL versioning (/v1/, /v2/), header versioning, and query parameter versioning. Versioning is essential for any externally consumed API. The operational burden is real: you have to keep old versions working while building new ones, and you need a deprecation strategy.
Citation Capsule: The 2025 Postman State of API Report found that organizations now manage an average of 421 APIs in production, and 73% of API-related outages stem from versioning failures or undocumented breaking changes (Postman, 2025).
These four patterns sit at the infrastructure layer, below your application code but above raw hardware. They're often taken for granted but they do significant architectural work.
40. CDN (Content Delivery Network) Static assets like images, videos, and JavaScript bundles get served from edge servers geographically close to the user, rather than from your origin server. This cuts latency for assets dramatically. The trade-off is cache invalidation: when you deploy a new version, you need to purge cached assets at the edge, which takes time to propagate.
41. Reverse Proxy A reverse proxy sits between your clients and your backend servers. It handles SSL termination, compression, response caching, and request routing. Nginx and Caddy are common examples. The reverse proxy is an essential component in production deployments. It adds a hop in the request path, which needs monitoring.
42. Service Mesh A dedicated infrastructure layer for service-to-service communication. Each service gets a sidecar proxy (typically Envoy) that intercepts all network traffic. The mesh handles load balancing, retries, circuit breaking, mutual TLS, and observability automatically, without any changes to application code. The operational complexity of running a service mesh is real and shouldn't be underestimated.
43. Sidecar Pattern A helper process runs alongside your main service in the same deployment unit (a pod in Kubernetes, for example). The sidecar handles cross-cutting concerns: logging, metrics collection, secret rotation, proxy behavior. The main service stays focused on business logic. The cost is increased resource consumption per instance.
Consistency is where distributed systems get philosophically interesting. You can't have perfect consistency, availability, and partition tolerance simultaneously (CAP theorem), so every consistency pattern is really a negotiated trade-off. Understanding what each pattern gives up is more valuable than knowing what it provides.
44. Two-Phase Commit (2PC) A coordinator asks all participating nodes: "can you commit this transaction?" If everyone says yes, it sends the commit command. If anyone says no, it sends rollback to everyone. This guarantees atomicity across multiple services. The problem is that the coordinator blocks while waiting for responses. With many participants, this becomes a bottleneck and a reliability risk.
45. Saga Pattern A long-running transaction gets broken into a sequence of local transactions. Each service completes its step and publishes an event to trigger the next. If any step fails, compensating transactions run in reverse to undo the previous steps. This avoids the blocking problem of 2PC, but there's a window of temporary inconsistency between when a step completes and when the compensation runs.
46. Quorum In a system with N replicas, a quorum requires that write acknowledgments (W) plus read acknowledgments (R) exceed N. If W + R > N, you're guaranteed that at least one node in any read quorum has the latest write. Higher W and R values give you stronger consistency but slower operations. Tuning quorum values is how systems like Cassandra let you trade consistency for speed.
47. Vector Clocks Each node maintains a logical timestamp that increments on every local operation. When nodes communicate, they exchange and merge their vector clocks. This lets you determine the causal ordering of events across nodes and identify when two writes genuinely conflict versus when one clearly happened before the other. The limitation is that the vector grows with the number of nodes, which can get large in big clusters.
You can't fix what you can't see. These three patterns give you visibility into what's actually happening in a distributed system. Without them, debugging production issues becomes guesswork.
48. Health Check Endpoint Every service exposes a dedicated endpoint that returns its current status. Load balancers poll this endpoint and stop routing traffic to instances that report unhealthy. Shallow health checks just confirm the process is running. Deep health checks verify that dependencies like databases and caches are also reachable. Deep checks are more informative but add latency to every health poll.
49. Distributed Tracing A single user request might touch 15 services before returning a response. Distributed tracing attaches a trace ID to the request at entry and passes it through every service. Each service records a "span" with timing data. You can reconstruct the full call path and see exactly where time was spent. At high request volumes, you need to sample traces rather than record every one, which means some issues only show up in samples.
50. Canary Deployment Roll out a new version to a small slice of your servers, maybe 1-5% of traffic, before deploying everywhere. Monitor error rates, latency, and business metrics for the canary group versus the stable group. If metrics look good, gradually increase the canary percentage. If something goes wrong, roll back only the canary instances. This catches real-traffic bugs that staging environments miss. The requirement is that the new and old versions must be compatible enough to run simultaneously.
Citation Capsule: A 2025 DORA report (DORA/Google, 2025) found that elite engineering teams deploy 973 times more frequently than low performers, and canary deployments combined with automated rollback are among the top three practices separating elite from average performers.
Most system design interview struggles come from jumping to solutions too early. Use these five questions to structure your thinking in any design interview:
1. What's the data flow? Understand how data moves through the system before deciding on components. This leads you to communication patterns (patterns 12–18).
2. Where does the data live? Decide on storage strategy based on data volume, write patterns, and consistency requirements. This leads to storage patterns (patterns 1–6).
3. How do we serve data quickly? Identify read-heavy paths and where caching makes sense. This leads to caching patterns (patterns 7–11).
4. How does the system survive failures? Enumerate failure modes and mitigation strategies for each. This leads to reliability patterns (patterns 19–25).
5. How does the system grow? Think about which components hit limits first at 10x current scale. This leads to scaling patterns (patterns 26–30).
Working through these questions before sketching a diagram keeps your answer structured and demonstrates genuine architectural thinking rather than pattern-matching to memorized designs.
Not all 50 patterns show up equally in interviews. Based on interview reports from engineers at Google, Meta, Amazon, and similar companies, these 15 come up most often:
Storage: Primary-Replica, Sharding, Consistent Hashing
Caching: Cache-Aside, Cache Stampede Prevention
Communication: Message Queue, Publish-Subscribe
Reliability: Circuit Breaker, Retry with Exponential Backoff, Idempotency
Scaling: Horizontal Scaling, Load Balancing, Auto-Scaling
API: API Gateway, Rate Limiting
If you're short on time, get these 15 down cold first. Then fill in the other 35 over time. One pattern a day for two months covers everything in this guide.
Most senior engineer interviews at FAANG-level companies focus on 10–15 patterns in depth, not all 50. According to Glassdoor interview data (Glassdoor, 2025), the most commonly tested patterns are circuit breakers, sharding, caching strategies, and message queues. That said, knowing all 50 means you can reach for the right tool when the interviewer takes the problem somewhere unexpected.
In a message queue, each message is consumed by exactly one consumer. Once it's processed, it's gone. In pub/sub, each message is delivered to every subscriber on the topic simultaneously. Use a queue when you want work distributed across competing workers. Use pub/sub when you want the same event delivered to multiple independent consumers, like sending the same order event to both your inventory service and your analytics service.
CQRS makes sense when read and write patterns are fundamentally different: high-volume reads with complex filtering, and lower-volume writes with strict consistency requirements. For most CRUD applications with modest traffic, CQRS adds complexity without meaningful benefit. A 2024 ThoughtWorks Technology Radar (ThoughtWorks, 2024) notes that CQRS is frequently adopted prematurely, before teams have validated that a simpler approach won't work.
2PC is synchronous and blocking: all participants must agree before any commit happens. Sagas are asynchronous and eventual: each step commits locally and publishes an event. If a saga step fails, compensating transactions undo the work done so far. 2PC is simpler to reason about but doesn't scale well across many services. Sagas scale well but introduce a window of inconsistency and require careful design of compensating logic for every failure scenario.
Fifty patterns is a lot. You won't internalize all of them in a weekend, and you shouldn't try. Start with the 15 most-tested patterns listed above and make sure you can explain each one, including its trade-offs, without hesitation. Then work outward from there.
The deeper value of studying patterns isn't the patterns themselves. It's developing the habit of thinking in trade-offs. Every pattern solves one problem and introduces another. The engineer who can say "I'd use a saga here because 2PC won't scale, and I'll handle the temporary inconsistency by..." is the engineer who gets hired and promoted.
For your next step, pick one pattern from each category that you haven't thought about deeply before. Write a short explanation of it in your own words, including the failure modes. That exercise alone will reveal gaps you didn't know you had.