System Design Patterns Reference

┌─────────────────────────┐
│   Presentation Layer    │  UI, API endpoints
├─────────────────────────┤
│    Business Layer       │  Business logic
├─────────────────────────┤
│   Persistence Layer     │  Data access
├─────────────────────────┤
│     Database Layer      │  Storage
└─────────────────────────┘

Use: Traditional applications
Pros: Simple, separation of concerns
Cons: Tight coupling, hard to scale parts

┌─────────┐ ┌─────────┐ ┌─────────┐
│ Service │ │ Service │ │ Service │
│    A    │ │    B    │ │    C    │
└────┬────┘ └────┬────┘ └────┬────┘
     │           │           │
     └───────────┼───────────┘
                 │
         Message Bus / API Gateway

Use: Large systems, multiple teams
Pros: Independent scaling, deployment
Cons: Distributed complexity, latency

┌──────────┐     Event      ┌──────────┐
│ Producer │───────────────►│  Event   │
└──────────┘                │   Bus    │
                            └────┬─────┘
           ┌─────────────────────┼─────────────────────┐
           │                     │                     │
      ┌────▼────┐          ┌────▼────┐          ┌────▼────┐
      │Consumer │          │Consumer │          │Consumer │
      │    A    │          │    B    │          │    C    │
      └─────────┘          └─────────┘          └─────────┘

Use: Decoupled systems, real-time
Pros: Loose coupling, scalable
Cons: Eventual consistency, debugging

┌─────────────────────────────────────────┐
│                 Client                  │
└──────────┬─────────────────┬────────────┘
           │                 │
      ┌────▼────┐       ┌────▼────┐
      │ Command │       │  Query  │
      │   API   │       │   API   │
      └────┬────┘       └────┬────┘
           │                 │
      ┌────▼────┐       ┌────▼────┐
      │  Write  │──────►│  Read   │
      │  Model  │ sync  │  Model  │
      └─────────┘       └─────────┘

Use: Complex domains, high read/write ratio
Pros: Optimized models, scalable
Cons: Complexity, eventual consistency

┌─────────┐    ┌─────────┐    ┌─────────┐
│Service A│    │Service B│    │Service C│
└────┬────┘    └────┬────┘    └────┬────┘
     │              │              │
┌────▼────┐    ┌────▼────┐    ┌────▼────┐
│   DB A  │    │   DB B  │    │   DB C  │
└─────────┘    └─────────┘    └─────────┘

Use: Microservices
Pros: Independence, right tool per service
Cons: Cross-service queries complex

Order Service    Payment Service    Inventory Service
     │                  │                   │
     ├─────Create Order─┼───────────────────┤
     │                  │                   │
     │                  ├───Charge Payment──┤
     │                  │                   │
     │                  │                   ├──Reserve Stock
     │                  │                   │
     │◄─────────────────┼───────────────────┤ Success
     │                  │                   │
     │   If failure:    │                   │
     │   ├──────────────┼───Refund──────────┤
     │   │              │                   │
     │   ├──Cancel Order┼───────────────────┤
     │                  │                   │

Use: Distributed transactions
Types: Choreography (events), Orchestration (coordinator)
Pros: No distributed locks
Cons: Complex rollback logic

┌─────────────────────────────────────────────┐
│                Event Store                   │
├─────────────────────────────────────────────┤
│ 1. AccountCreated(id=123, balance=0)        │
│ 2. MoneyDeposited(id=123, amount=100)       │
│ 3. MoneyWithdrawn(id=123, amount=30)        │
│ 4. MoneyDeposited(id=123, amount=50)        │
├─────────────────────────────────────────────┤
│ Current State = Replay Events → Balance: 120│
└─────────────────────────────────────────────┘

Use: Audit trails, temporal queries
Pros: Full history, rebuild state
Cons: Complexity, storage growth

Range Sharding:          Hash Sharding:           Directory Sharding:
┌───────────┐           ┌───────────┐            ┌───────────┐
│ A-M → S1  │           │hash(key)  │            │ Lookup    │
│ N-Z → S2  │           │  % N      │            │ Service   │
└───────────┘           └───────────┘            └───────────┘

Use: Range for scans, Hash for distribution
Pros: Horizontal scaling
Cons: Cross-shard queries, resharding

┌─────────────────────────────────────────┐
│              API Gateway                 │
├─────────────────────────────────────────┤
│ • Rate limiting      • Authentication   │
│ • Request routing    • Load balancing   │
│ • Response caching   • SSL termination  │
└──────────────────┬──────────────────────┘
                   │
    ┌──────────────┼──────────────┐
    │              │              │
┌───▼───┐     ┌───▼───┐     ┌───▼───┐
│Svc A  │     │Svc B  │     │Svc C  │
└───────┘     └───────┘     └───────┘

Use: Microservices entry point
Pros: Centralized concerns
Cons: Single point of failure

┌─────────────────────────────────────────┐
│                                         │
│  ┌─────────┐         ┌─────────┐       │
│  │Service A│◄───────►│Service B│       │
│  │ ┌─────┐ │         │ ┌─────┐ │       │
│  │ │Proxy│ │         │ │Proxy│ │       │
│  │ └─────┘ │         │ └─────┘ │       │
│  └─────────┘         └─────────┘       │
│                                         │
│  Control Plane (Istio/Linkerd)         │
│  • Traffic management • Security       │
│  • Observability     • Policy          │
│                                         │
└─────────────────────────────────────────┘

Use: Complex microservices
Pros: Consistent networking, observability
Cons: Operational complexity

         ┌─────────────────────────────┐
         │                             │
         │   CLOSED ◄──────────────────┤
         │     │                       │
         │     │ failures > threshold  │
         │     ▼                       │
         │   OPEN ─────────────────────┤
         │     │                       │
         │     │ timeout expires       │
         │     ▼                       │
         │  HALF-OPEN                  │
         │     │                       │
         │     ├── success → CLOSED    │
         │     └── failure → OPEN      │
         │                             │
         └─────────────────────────────┘

Use: Prevent cascade failures
Pros: Fast fails, recovery time
Cons: Needs tuning

Attempt 1: Immediate
Attempt 2: Wait 1s
Attempt 3: Wait 2s
Attempt 4: Wait 4s  (exponential)
Attempt 5: Wait 8s + random jitter

With jitter to prevent thundering herd:
delay = min(cap, base * 2^attempt) + random(0, 1)

Use: Transient failures
Pros: Handles temporary issues
Cons: Increased latency on failure

                Load Balancer
                     │
    ┌────────────────┼────────────────┐
    │                │                │
┌───▼───┐       ┌───▼───┐       ┌───▼───┐
│Server │       │Server │       │Server │
│   1   │       │   2   │       │   N   │
└───────┘       └───────┘       └───────┘

Use: Stateless services
Pros: Linear scaling, redundancy
Cons: State management, complexity

┌─────────────────┐     ┌─────────────────┐
│    Small VM     │ →   │    Large VM     │
│  2 CPU, 4GB     │     │  16 CPU, 64GB   │
└─────────────────┘     └─────────────────┘

Use: Quick fix, databases
Pros: Simple, no code changes
Cons: Hardware limits, downtime

┌─────────────────────────────────────────┐
│            Auto-Scaling Group           │
├─────────────────────────────────────────┤
│ Min: 2    Desired: 4    Max: 10        │
│                                         │
│ Scale Out: CPU > 70% for 5 min         │
│ Scale In:  CPU < 30% for 10 min        │
│                                         │
│ Cooldown: 300 seconds                   │
└─────────────────────────────────────────┘

Use: Variable load
Pros: Cost efficiency, handles spikes
Cons: Cold start, configuration complexity

/health/live   → Is process running?
/health/ready  → Can handle traffic?
/health/deep   → Are dependencies OK?

Response: {"status": "healthy", "checks": {...}}

Use: Load balancers, orchestrators
Pros: Automated recovery
Cons: False positives/negatives

┌─────────────────────────────────────────┐
│              Application                │
├────────────┬────────────┬───────────────┤
│ Thread Pool│ Thread Pool│ Thread Pool  │
│     A      │     B      │     C        │
│ (critical) │ (normal)   │ (background) │
└────────────┴────────────┴───────────────┘

Use: Resource isolation
Pros: Contains failures
Cons: Resource overhead

100% Load:  Full features
├─────────────────────────
│ 80%: Disable recommendations
│ 60%: Serve cached content
│ 40%: Text-only mode
│ 20%: Maintenance page
└─────────────────────────

Use: Overload protection
Pros: Partial service better than none
Cons: Feature complexity

1. App checks cache
2. Cache miss → Read from DB
3. App writes to cache
4. Return data

┌─────┐      ┌─────┐      ┌────┐
│ App │─────►│Cache│      │ DB │
└──┬──┘      └─────┘      └──▲─┘
   │                         │
   └─────────────────────────┘
         Cache miss

Use: General purpose
Pros: Simple, lazy loading
Cons: Cache misses slow

1. App writes to cache
2. Cache writes to DB
3. Both updated synchronously

┌─────┐      ┌─────┐      ┌────┐
│ App │─────►│Cache│─────►│ DB │
└─────┘      └─────┘      └────┘

Use: Strong consistency needed
Pros: Data always in sync
Cons: Write latency

1. App writes to cache
2. Cache ACKs immediately
3. Cache writes to DB async

┌─────┐      ┌─────┐  async  ┌────┐
│ App │─────►│Cache│ ─ ─ ─ ─►│ DB │
└─────┘      └─────┘         └────┘

Use: Write-heavy workloads
Pros: Fast writes
Cons: Data loss risk

Token Bucket:
• Bucket fills at constant rate
• Request takes a token
• No token = rejected

Sliding Window:
• Count requests in time window
• Window slides forward
• Smoother than fixed window

Leaky Bucket:
• Requests queue up
• Process at constant rate
• Queue full = rejected

Session-Based:               Token-Based (JWT):
┌─────────┐                  ┌─────────┐
│ Session │ ◄─── Cookie      │  JWT    │ ◄─── Header
│  Store  │                  │ Payload │
└─────────┘                  └─────────┘
• Stateful                   • Stateless
• Easy revocation            • No DB lookup
• Scaling needs sync         • Scales easily

Publisher ─────► Topic ─────► Subscriber A
                   │
                   └────────► Subscriber B

Use: Event broadcasting
Pros: Decoupled, scalable
Cons: No delivery guarantee

Producer ─────► Queue ─────► Consumer

Use: Work distribution
Pros: Load leveling, reliability
Cons: Single consumer per message

Client ─── Request ──► Service
       ◄── Reply ─────

Async version:
Client ─── Request ──► Request Queue ─► Service
       ◄── Reply ───── Reply Queue ◄────

Use: RPC-style communication
Pros: Familiar pattern
Cons: Coupling, latency

Request ID: abc-123
├── API Gateway (10ms)
│   └── Auth Service (5ms)
├── Order Service (50ms)
│   ├── Inventory Service (20ms)
│   └── Payment Service (25ms)
└── Notification Service (15ms)

Total: 100ms

Use: Debugging distributed systems
Tools: Jaeger, Zipkin, X-Ray

┌─────────┐  ┌─────────┐  ┌─────────┐
│Service A│  │Service B│  │Service C│
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┼────────────┘
                  │
           ┌──────▼──────┐
           │ Log Shipper │  (Filebeat, Fluentd)
           └──────┬──────┘
                  │
           ┌──────▼──────┐
           │  Search &   │  (Elasticsearch)
           │   Index     │
           └──────┬──────┘
                  │
           ┌──────▼──────┐
           │ Visualization│ (Kibana, Grafana)
           └─────────────┘

Use: Centralized logging
Pros: Searchable, correlated