All Roadmaps›🏛️ System Design›Phase 14›System Design Patterns — Quick Reference

System Design Patterns — Quick Reference

0/2 in this phase0/45 across the roadmap

📖 Concept

A summary of all major patterns you should know for system design interviews.

Data Patterns

Pattern When to Use Example
Sharding DB too large for single server Partition users by user_id hash
Replication Read scalability, fault tolerance Primary + read replicas
Denormalization Eliminate expensive JOINs Store author_name in posts table
CQRS Different read/write optimizations Write to PostgreSQL, read from Elasticsearch
Event Sourcing Need full audit trail Bank transactions, shopping cart

Communication Patterns

Pattern When to Use Example
Sync (REST/gRPC) Need immediate response User authentication
Async (Queue) Can process later Email sending, analytics
Pub/Sub One event → multiple consumers Order created → inventory + notification
WebSocket Real-time bidirectional Chat, live scores, collaboration

Reliability Patterns

Pattern What It Does When to Use
Circuit Breaker Stops calling failing services Any service-to-service call
Retry + Backoff Retries with increasing delay Transient failures
Bulkhead Isolates failure domains Critical + non-critical services
Rate Limiting Controls request rate API protection, abuse prevention
Timeout Limits wait time Every external call

Scaling Patterns

Pattern How It Scales When to Use
Load Balancing Distributes traffic across servers Always for horizontal scaling
CDN Caches content at edge locations Static assets, global users
Caching Stores hot data in memory Read-heavy workloads
Queue Buffers work for async processing Traffic spikes, decoupling
Auto-Scaling Adjusts instance count dynamically Variable traffic patterns

The Interview Decision Matrix

When making design decisions, use this matrix:

Question Consider
"How to store data?" SQL vs NoSQL vs Object Storage
"How to scale reads?" Caching → Read replicas → CDN
"How to scale writes?" Queue → Sharding → CQRS
"How to communicate?" Sync (REST/gRPC) vs Async (Queue) vs Real-time (WebSocket)
"How to handle failures?" Circuit breaker + Retry + Timeout + Fallback
"How to ensure consistency?" Strong (ACID) vs Eventual (BASE) — per component
"How to generate IDs?" Snowflake (time-sorted) vs UUID (random)
"How to distribute data?" Consistent hashing vs Range-based sharding

Final tip: System design is about trade-offs, not perfection. Every decision has pros and cons. The best candidates explicitly state the trade-offs and explain why their choice is optimal for the given requirements.

💻 Code Example

codeTap to expand ⛶
1// ============================================
2// System Design Patterns — Quick Reference Code
3// ============================================
4

5// This is a consolidated reference of all the key patterns
6// covered throughout this roadmap.
7

8// ---------- Pattern Decision Engine ----------
9function recommendArchitecture(requirements) {
10  const arch = {
11    database: null,
12    cache: null,
13    queue: null,
14    loadBalancer: null,
15    communication: null,
16    idGeneration: null,
17  };
18

19  // Database selection
20  if (requirements.complexRelations) {
21    arch.database = 'PostgreSQL (SQL, ACID, JOINs)';
22  } else if (requirements.writeHeavy) {
23    arch.database = 'Cassandra (write-optimized, eventual consistency)';
24  } else if (requirements.flexibleSchema) {
25    arch.database = 'MongoDB (document model, flexible schema)';
26  } else if (requirements.graphRelations) {
27    arch.database = 'Neo4j (graph traversal)';
28  } else {
29    arch.database = 'PostgreSQL (safe default)';
30  }
31

32  // Caching
33  if (requirements.readWriteRatio > 10) {
34    arch.cache = 'Redis (cache-aside with TTL)';
35  }
36  if (requirements.globalUsers) {
37    arch.cache += ' + CDN (edge caching)';
38  }
39

40  // Message Queue
41  if (requirements.asyncProcessing) {
42    if (requirements.eventStreaming) {
43      arch.queue = 'Kafka (event streaming, replay capability)';
44    } else {
45      arch.queue = 'RabbitMQ or SQS (simple task queue)';
46    }
47  }
48

49  // Communication
50  if (requirements.realTime) {
51    arch.communication = 'WebSocket (bidirectional real-time)';
52  } else if (requirements.internalService) {
53    arch.communication = 'gRPC (efficient inter-service)';
54  } else {
55    arch.communication = 'REST over HTTPS (standard API)';
56  }
57

58  // ID Generation
59  if (requirements.distributed) {
60    arch.idGeneration = 'Snowflake IDs (time-sorted, globally unique)';
61  } else {
62    arch.idGeneration = 'Auto-increment (simple, sequential)';
63  }
64

65  // Load Balancer
66  arch.loadBalancer = requirements.scale > 10000
67    ? 'L7 Load Balancer (ALB) + Auto-Scaling'
68    : 'Nginx (simple reverse proxy)';
69

70  return arch;
71}
72

73// Example: Design decisions for a social media platform
74console.log('\nSocial Media Architecture:');
75console.log(recommendArchitecture({
76  complexRelations: true,   // Users, posts, follows
77  writeHeavy: false,
78  flexibleSchema: false,
79  graphRelations: true,     // Social graph
80  readWriteRatio: 100,      // Read-heavy
81  globalUsers: true,
82  asyncProcessing: true,    // Notifications, analytics
83  eventStreaming: true,      // Feed fan-out
84  realTime: true,           // Chat, live updates
85  internalService: true,    // Microservices
86  distributed: true,
87  scale: 1000000,
88}));
89

90// Example: Design decisions for a banking system
91console.log('\nBanking System Architecture:');
92console.log(recommendArchitecture({
93  complexRelations: true,
94  writeHeavy: false,
95  flexibleSchema: false,
96  graphRelations: false,
97  readWriteRatio: 5,
98  globalUsers: false,
99  asyncProcessing: true,    // Statement generation
100  eventStreaming: false,
101  realTime: false,
102  internalService: true,
103  distributed: true,
104  scale: 50000,
105}));

🏋️ Practice Exercise

  1. Pattern Matching: For each real-world system, identify ALL patterns used: (a) Netflix, (b) Uber, (c) Amazon, (d) Slack. Create a table mapping each pattern to how it's used.

  2. Trade-off Presentation: Pick 5 design decisions from the matrix. For each, prepare a 2-minute explanation of when to choose each option and why.

  3. Mock Interview: Practice a full 45-minute system design interview with a friend or rubber duck. Record yourself and review for: structure, clarity, trade-off discussion, and time management.

  4. Component Deep Dive: For each component in your favorite system design (database, cache, queue, LB), explain: (a) why this specific technology, (b) what alternatives you considered, (c) the trade-offs.

⚠️ Common Mistakes

  • Memorizing architectures instead of understanding trade-offs — interviewers detect rehearsed answers. Understand WHY each component is chosen, not just WHAT to draw.

  • Not practicing under time pressure — 45 minutes feels very short. Practice with a timer. Allocate time strictly: 5 min requirements, 5 min estimation, 15 min design, 15 min deep dive.

  • Ignoring the interviewer's hints — if they ask 'what about consistency here?', they're guiding you toward an important discussion point. Follow their lead.

  • Not drawing diagrams — a picture is worth a thousand words. Draw boxes, arrows, and label data flows. It makes your design concrete and easy to discuss.

💼 Interview Questions

🎤 Mock Interview

Practice a live interview for System Design Patterns — Quick Reference

← PreviousSystem Design Interview Framework