System Design Patterns.
Cheat sheet.

Essential design patterns for system architecture interviews. Covers architectural patterns (microservices, serverless), data management (CQRS, Event Sourcing), communication patterns (API Gateway, Service Mesh), and reliability patterns (Circuit Breaker, Bulkhead). Critical knowledge for designing robust, scalable systems.

1. Monolithic Architecture

Definition: Single deployable unit containing all functionality.

When to Use:

• Small applications
• Simple deployment requirements
• Tight budget/timeline

Trade-offs:

• ✅ Simple to develop and deploy
• ✅ Easy debugging
• ❌ Difficult to scale individual components
• ❌ Technology lock-in

2. Microservices Architecture

Definition: Application as a suite of small, independently deployable services.

When to Use:

• Large, complex applications
• Multiple teams
• Need for independent scaling

Trade-offs:

• ✅ Independent deployment/scaling
• ✅ Technology flexibility
• ❌ Increased complexity
• ❌ Network latency

Example Structure:

User Service → Database
Order Service → Database  
Payment Service → Database

3. Serverless Architecture

Definition: Code runs in stateless compute containers managed by cloud providers.

When to Use:

• Variable/unpredictable traffic
• Event-driven workloads
• Rapid prototyping

Trade-offs:

• ✅ No server management
• ✅ Auto-scaling
• ❌ Vendor lock-in
• ❌ Cold starts

4. Event-Driven Architecture

Definition: Components communicate through events rather than direct calls.

When to Use:

• Loosely coupled systems
• Real-time data processing
• Complex workflows

Components:

• Event Producers
• Event Router (Message Queue/Stream)
• Event Consumers

1. Database Per Service

Definition: Each microservice owns its database.

Benefits:

• Service independence
• Technology flexibility
• Isolated failures

Challenge: Cross-service queries require API calls or data synchronization.

2. Shared Database

Definition: Multiple services share the same database.

When to Use:

• Strong consistency requirements
• Simple transactions
• Small number of services

Trade-offs:

• ✅ ACID transactions
• ✅ Simple queries
• ❌ Tight coupling
• ❌ Scaling bottlenecks

3. CQRS (Command Query Responsibility Segregation)

Definition: Separate models for reads and writes.

Commands (Write) → Write DB
                      ↓
                 Event Store
                      ↓
Queries (Read) ← Read DB (Optimized Views)

When to Use:

• Complex domains
• Different read/write patterns
• High read-to-write ratio

4. Event Sourcing

Definition: Store state changes as sequence of events.

Example:

OrderCreated → ItemAdded → PaymentProcessed → OrderShipped

Benefits:

• Complete audit trail
• Time travel debugging
• Event replay

5. Saga Pattern

Definition: Manage distributed transactions as sequence of local transactions.

Types:

• Choreography: Each service publishes events
• Orchestration: Central coordinator manages flow

Example Flow:

Order Service → Payment Service → Inventory Service
     ↓                ↓                  ↓
  Success          Success           Success
     ↓                                   ↓
  Continue                          If Failure
                                        ↓
                                  Compensate

1. API Gateway

Definition: Single entry point for all client requests.

Responsibilities:

• Request routing
• Authentication
• Rate limiting
• Load balancing
• Response aggregation

Client → API Gateway → Service A
                    → Service B
                    → Service C

2. Service Mesh

Definition: Dedicated infrastructure layer for service-to-service communication.

Features:

• Traffic management
• Security (mTLS)
• Observability
• Resilience

Popular Tools: Istio, Linkerd

3. Message Queue Pattern

Definition: Asynchronous communication via message broker.

Types:

• Point-to-Point: One producer, one consumer
• Publish-Subscribe: One producer, multiple consumers

When to Use:

• Decoupling services
• Handling traffic spikes
• Reliable delivery needed

4. Backend for Frontend (BFF)

Definition: Separate backend services for different frontend applications.

Mobile App → Mobile BFF → Microservices
Web App → Web BFF → Microservices

Benefits:

• Optimized APIs per client
• Reduced over-fetching
• Client-specific logic

1. Circuit Breaker

Definition: Prevent cascading failures by stopping requests to failing services.

States:

1. Closed: Normal operation
2. Open: Requests fail immediately
3. Half-Open: Test if service recovered

# Conceptual example
if failures > threshold:
    state = OPEN
    return cached_response
elif state == HALF_OPEN:
    try_request()

2. Retry Pattern

Definition: Automatically retry failed operations.

Best Practices:

• Exponential backoff
• Maximum retry limit
• Idempotent operations only

Retry Delays: 1s → 2s → 4s → 8s → Fail

3. Bulkhead Pattern

Definition: Isolate resources to prevent total system failure.

Implementation:

• Thread pool isolation
• Connection pool limits
• Rate limiting per service

4. Health Check Pattern

Definition: Endpoints to verify service availability.

Types:

• Liveness: Is service running?
• Readiness: Can service handle requests?

GET /health
{
  "status": "healthy",
  "database": "connected",
  "cache": "connected"
}

1. Caching Strategies

Cache-Aside (Lazy Loading):

1. Check cache
2. If miss → fetch from DB → update cache
3. Return data

Write-Through:

1. Write to cache
2. Cache writes to DB
3. Return success

Write-Behind:

1. Write to cache
2. Return success
3. Cache writes to DB asynchronously

2. CDN (Content Delivery Network)

Definition: Geographically distributed servers for static content.

Benefits:

• Reduced latency
• Decreased server load
• Better availability

3. Database Sharding

Definition: Horizontal partitioning of data across multiple databases.

Strategies:

• Range-based: By ID range (1-1000, 1001-2000)
• Hash-based: By hash(key) % shards
• Geographic: By user location

4. Read Replicas

Definition: Multiple read-only database copies.

Write → Master DB
           ↓
    Replication
     ↓    ↓    ↓
  Read  Read  Read
  Replica Replicas

5. Load Balancing Algorithms

Round Robin: Requests distributed sequentially
Least Connections: Route to server with fewest connections
Weighted: Based on server capacity
IP Hash: Consistent routing based on client IP

1. Authentication & Authorization

OAuth 2.0 Flow:

1. User → Authorization Server
2. User grants permission
3. Auth Server → Access Token
4. Client uses token → Resource Server

JWT Structure:

Header.Payload.Signature

2. API Rate Limiting

Algorithms:

• Token Bucket: Fixed capacity, refills at constant rate
• Sliding Window: Track requests in time window
• Fixed Window: Reset counter at intervals

3. Encryption Patterns

At Rest: Encrypt stored data
In Transit: TLS/SSL for communication
End-to-End: Client-to-client encryption

Key Questions to Consider:

1. Scale: How many users? Requests per second?
2. Performance: Latency requirements? Throughput?
3. Reliability: Availability targets? Data consistency?
4. Security: Authentication needs? Data sensitivity?

Design Process:

1. Clarify Requirements: Functional and non-functional
2. Estimate Scale: Back-of-envelope calculations
3. Define APIs: REST/GraphQL interfaces
4. Data Model: Schema and storage choices
5. High-Level Design: Component diagram
6. Detailed Design: Address bottlenecks
7. Scale & Optimize: Caching, sharding, CDN
8. Handle Failures: Reliability patterns
9. Monitor: Metrics and logging

Common Pitfalls:

• Over-engineering for initial requirements
• Ignoring data consistency
• Not considering failure scenarios
• Forgetting about monitoring/debugging

Remember:

• Start simple, evolve the design
• Justify decisions with trade-offs
• Consider alternatives and explain choices
• Think about operations: deployment, monitoring, debugging