System Design Patterns

The 15 patterns that come up in 90% of system-design interviews, distilled from Alex Xu’s System Design Interview and Martin Kleppmann’s Designing Data-Intensive Applications.

Patterns at a Glance

#	Pattern	Use when…	Failure mode if misused
1	Caching	Read-heavy, latency-sensitive	Stale cache, thundering herd
2	Sharding	Data exceeds 1 server	Hot shard, cross-shard joins
3	Replication	Need availability	Replication lag, stale reads
4	Load Balancing	Multi-instance backend	Single-bucket routing, no health checks
5	Message Queues	Burst smoothing, decoupling	Poison messages, dead-letter pile-up
6	CAP Theorem	Choosing a database	Wrong trade-off for the workload
7	Saga	Multi-service transaction	Compensating logic bugs
8	CQRS	Read vs write scaling differ	Eventual consistency bugs
9	Rate Limiting	Public APIs	Burst wrong, false positives
10	Idempotency Keys	Network retries on writes	Double-charge bugs
11	Circuit Breaker	Unstable downstream deps	Cascading failure
12	Consistent Hashing	Dynamic cache/DB cluster	Uneven load if vnodes too few
13	Leader Election	Single-coordinator need	Split-brain
14	Event Sourcing	Audit log / time travel	Event-versioning mishaps
15	Bulkhead	Multi-tenant workloads	Thread-pool starvation

How They Compose

A typical large system stacks many of these together. Example: a chat app

       client
         |
         v
   [ Load Balancer L7 ] -- health checks
         |
         v
   [ API fleet ] -- Bulkhead (tenant-isolated pools)
     |        |
     v        v
  [Cache]  [RateLimiter] -- token bucket
     |        |
     v        v
  [Service]  [Saga Orchestrator]
     |        |
     v        v
  [Replicated DB]  [Message Queue]  -->  downstream workers
                                      -->  [Event Store]

Every real system combines 5-10 of these. The interview is NOT “which one?”, it is “which ones, in what order, and what’s the trade-off?”.