You don't need to memorize 200 distributed systems papers. In my experience, 8 core patterns cover ~80% of system design interviews.
Here are 8 system design patterns you'll see most often.
1. Load Balancing
When asked: "Design a system that handles millions of requests"
Client → Load Balancer → [Server 1, Server 2, Server N]
Key strategies:
- Round Robin — Simple, equal distribution
- Least Connections — Route to least busy server
- Consistent Hashing — Sticky sessions without state
Interview tip: Always mention health checks. A load balancer that routes to dead servers is worse than no load balancer.
Complexity: O(1) routing decision, O(N) health check cycle
2. Caching (Read-Through vs Write-Through)
When asked: "How do you handle 100x read traffic?"
App → Cache (hit?) → yes → return
→ no → DB → populate cache → return
Read-Through: Cache sits between app and DB. Miss → fetch → cache → return.
Write-Through: Every write goes to cache AND DB simultaneously.
Write-Behind: Write to cache, async flush to DB (risky but fast).
Cache invalidation strategies:
| Strategy | Consistency | Complexity |
|----------|------------|------------|
| TTL | Eventually | Low |
| Write-through | Strong | Medium |
| Event-driven | Near-real-time | High |
Interview tip: "Cache invalidation is one of two hard problems in CS." Always discuss your invalidation strategy.
3. Database Sharding
When asked: "Your single DB can't handle the load"
Horizontal sharding splits rows across multiple databases:
-
Hash-based:
shard = hash(user_id) % N - Range-based: Users A-M → Shard 1, N-Z → Shard 2
- Directory-based: Lookup table maps keys to shards
Tradeoffs:
| Type | Even distribution | Range queries | Resharding |
|---|---|---|---|
| Hash | ✅ Great | ❌ Hard | ❌ Painful |
| Range | ⚠️ Hotspots | ✅ Natural | ✅ Easy |
| Directory | ✅ Flexible | ✅ Flexible | ⚠️ Single point |
Interview tip: Hash sharding + consistent hashing = minimal data movement when adding shards.
4. Message Queues (Async Processing)
When asked: "How do you handle spiky traffic?" or "How do you decouple services?"
Producer → Queue → Consumer(s)
When to use:
- Spiky workloads (Black Friday orders)
- Long-running tasks (video encoding, email sending)
- Service decoupling (payment → notification → analytics)
Delivery guarantees:
| Guarantee | Use case | Example |
|---|---|---|
| At-most-once | Logging, metrics | Fire and forget |
| At-least-once | Payments, orders | Retry + idempotency |
| Exactly-once | Financial transactions | Kafka transactions |
Interview tip: Always pair "at-least-once" with idempotency keys.
5. API Gateway Pattern
When asked: "Design the entry point for a microservices system"
Client → API Gateway → Auth → Rate Limit → Route → Service
Responsibilities:
- Authentication & authorization
- Rate limiting & throttling
- Request routing & load balancing
- Response caching
- Request/response transformation
Real-world: Netflix Zuul handles 50B+ requests/day through their API gateway.
Interview tip: API gateway = single point of failure. Always discuss redundancy.
6. Event Sourcing + CQRS
When asked: "Design an audit trail" or "Design a banking system"
Instead of storing current state, store every event:
Event Store: [AccountCreated, Deposited $100, Withdrew $30, ...]
Current State: Balance = $70 (replay events)
CQRS (Command Query Responsibility Segregation):
- Write model: Append events (optimized for writes)
- Read model: Materialized views (optimized for queries)
When to use: Financial systems, audit logs, collaborative editing
When NOT to use: Simple CRUD apps (massive overkill)
7. Circuit Breaker
When asked: "How do you handle cascading failures?"
States: CLOSED → (failures exceed threshold) → OPEN
OPEN → (timeout) → HALF-OPEN → (success) → CLOSED
→ (failure) → OPEN
Thresholds:
- Failure rate: >50% in last 10 requests → OPEN
- Timeout: 30 seconds before HALF-OPEN
- Half-open: Allow 3 test requests
Interview tip: Combine with retry + exponential backoff + jitter. Never retry without backoff.
8. Consistent Hashing
When asked: "Design a distributed cache" or "Add/remove servers without resharding everything"
Traditional hashing: server = hash(key) % N → Adding one server moves ~100% of keys.
Consistent hashing: Keys and servers on a ring → Adding one server moves only ~1/N of keys.
Virtual nodes: Each physical server gets 100-200 positions on the ring → even distribution.
Used by: DynamoDB, Cassandra, Akamai CDN, Discord
Interview tip: Always mention virtual nodes. Without them, distribution is uneven.
That's 8 of 40.
These 8 patterns handle most system design questions at the senior level. But interviews also ask about:
- Rate limiting algorithms (Token bucket, Sliding window)
- Consensus protocols (Raft, Paxos)
- CDN design (Push vs Pull, Edge caching)
- Search systems (Inverted index, Ranking)
- Notification systems (Fan-out, Priority queues)
- ...and 27 more patterns
More by MaxMini
🛠️ 27+ Free Developer Tools — JSON formatter, UUID generator, password analyzer, and more. All browser-based, no signup.
🎮 27 Browser Games — Built with vanilla JS. Play instantly, no install.
📚 Developer Resources on Gumroad — AI prompt packs, automation playbooks, and productivity guides.
💰 DonFlow — Free budget tracker. Plan vs reality, zero backend.
~6,000 words covering every pattern from load balancing to consensus protocols, with decision flowcharts and mini-designs (URL shortener, chat system, news feed, etc.).
More interview prep:
🏦 Building a budgeting tool? Check out DonFlow — a zero-backend budget drift detector that runs entirely in your browser.
Top comments (0)