The 30 reusable pieces that system designs are assembled from. Learn these once and they apply to every question you are asked.
Interview questions look different from each other on the surface. The pieces you build them from do not. A URL shortener, a news feed, and a ride-hailing service all need the same small set of building blocks, arranged differently.
Each page here is short and practical: what the pattern is, when to use it, the trade-offs, and how to talk about it in an interview.
If you learn only five, learn these. They appear in almost every design.
- Caching, the most-read page in this directory and the first answer to most latency problems.
- Load balancing, how traffic reaches more than one machine.
- Sharding and partitioning, how data grows past one machine.
- Replication, how the system survives a machine dying.
- Consistency models, the vocabulary for what a read is allowed to return.
| What you are trying to do | Start with |
|---|---|
| Make reads faster | Caching, CDN, database indexing |
| Handle more traffic than one machine can | Load balancing, sharding, replication |
| Decide what a read is allowed to return | Consistency models, CAP theorem, quorum |
| Connect services without coupling them | Message queues, outbox, event sourcing and CQRS |
| Survive a machine or a dependency failing | Heartbeats, circuit breaker, leader election |
| Make a retry safe | Idempotency, write-ahead log |
| Protect a service from overload | Rate limiting, backpressure |
| Push updates to a client in real time | Long polling, WebSockets, and SSE |
| Change data in two places at once | Distributed transactions, distributed locking |
| Pattern | What it solves |
|---|---|
| Caching | Read latency and load on the data store |
| CDN | Serving static content close to users |
| Database indexing | Fast lookups |
| Bloom filters | Cheap "definitely not present" checks |
| Proxies | Intermediaries for routing, security, and caching |
| Pattern | What it solves |
|---|---|
| Load balancing | Distributing traffic across servers |
| Sharding and partitioning | Scaling data beyond one machine |
| Consistent hashing | Even distribution with minimal reshuffling |
| Replication | Availability and read scaling |
| API gateway | One entry point for auth, rate limiting, and routing |
| Pattern | What it solves |
|---|---|
| Consistency models | Correctness under concurrency |
| CAP theorem | Reasoning about trade-offs under partitions |
| Quorum | Consistent reads and writes across replicas |
| Leader election | Agreeing on one node in charge, surviving failover |
| Logical clocks (Lamport and vector) | Ordering events when wall clocks cannot be trusted |
| Distributed locking | Mutual exclusion across machines |
| Gossip protocol | Cluster membership and health without a coordinator |
| Pattern | What it solves |
|---|---|
| Message queues | Decoupling and async processing |
| Batch vs stream processing | Computing over big data, on a schedule or in real time |
| Backpressure | Pushing back on producers instead of buffering without limit |
| Long polling vs WebSockets vs SSE | Pushing real-time updates to clients |
| Pattern | What it solves |
|---|---|
| Idempotency | Making retries safe, no duplicate effects |
| Write-ahead log | Durability and crash recovery |
| Checksums | Detecting corrupted data |
| Heartbeats | Detecting failed servers |
| Circuit breaker | Stopping cascading failures |
| Rate limiting | Protecting services from overload |
| Distributed transactions (2PC vs sagas) | One operation across many services, correctly |
| Event sourcing and CQRS | State as an event log, plus purpose-built read views |
| Outbox pattern | Publishing events reliably alongside database writes |
A pattern page explains the mechanism. A cheat sheet is the decision: when a pattern has several common options, the sheet tells you which to pick and why. Caching explains how a cache works, and caching strategies picks between cache-aside, write-through, and the rest.
The questions apply the patterns end to end, and the deep dives show real systems that made these same choices.
- Copy _template.md to
patterns/your-pattern.md. - Fill in each section, including the one-line summary directly under the title.
- Add a row to the right table above and, if it is a core pattern, to the table in the root README.
- Every pattern in depth, with interactive diagrams: System Design Patterns: From Fundamentals to Real Systems
- Full course: Grokking the System Design Interview