System Design + Patterns

Introduction

System design + patterns is the layer above GoF: how patterns compose in distributed systems. URL shortener, ride-hailing, checkout — which patterns where, why, and what trade-offs each composition implies.

The story

Staff engineer asked to design global payment platform in 45 min. Drew API Gateway → BFFs → Saga → 8 services → Outbox each → Kafka → projections, naming each pattern. Interviewer: "Most draw boxes; you drew patterns with names." Offer in 24 hours.

The business problem

System design interviews reward named patterns at seams, not anonymous boxes:

• Box diagrams: no vocabulary — can't discuss trade-offs.
• Missing resilience: no breaker, saga, outbox at failure points.
• Monolith disguised: microservices without clear boundaries.
• No data strategy: CQRS/ES omitted when read scale matters.

The problem teams faced

System design + patterns requires:

• Name pattern at each architectural seam as you draw.
• Compose: Gateway, BFF, Saga, Outbox, CQRS where forces appear.
• Articulate trade-off per composition choice.
• Scale discussion: what breaks first, which pattern addresses it.

Understanding the topic

Intent: Map enterprise patterns onto system design scenarios.

• Edge: API Gateway, BFF, rate limit, auth.
• Workflow: Saga, Outbox, Circuit Breaker.
• Data: CQRS, Event Sourcing, Repository.
• Integration: Adapter, ACL, Strangler.

Internal architecture

Checkout system design annotation:

Client → API Gateway → Checkout BFF
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   Pricing      Inventory    Payment
   (Strategy)   (Repository) (Adapter + Circuit Breaker)
        │           │           │
        └───── Saga orchestrator ─┘
                    │
              Outbox → events → Notification (Strategy per channel)

Visual explanation

Three diagrams cover payment platform sketch, checkout composition, URL shortener:

Informative example

Naming while drawing — anonymous vs patterned:

// ❌ Anonymous boxes
[Service A] → [Service B] → [DB]

// ✅ Named patterns at seams
Client → API Gateway → Order BFF
              → Saga orchestrator
              → Payment service (Adapter + Circuit Breaker on Stripe client)
              → Outbox table → relay → Kafka → Notification (Strategy: email/sms)

Execution workflow

Real-world use

Staff+ system design loops at FAANG; domain-driven design workshops; architecture review boards expecting named patterns in RFCs.

Production case study

45-minute payment platform design:

• Approach: named Gateway, BFF, Saga, Outbox, CQRS on read path.
• Signal: patterns with names, not anonymous microservices.
• Outcome: offer extended within 24 hours.

Trade-offs

• Pro: vocabulary enables precise trade-off discussion.
• Con: over-patterning small systems in interview — scope appropriately.

Decision framework

• Distributed workflow → Saga + Outbox.
• Multiple clients → Gateway + optional BFF.
• Read-heavy → CQRS + cache.
• External API → Adapter + Circuit Breaker.

Best practices

• Say pattern name aloud as you draw the box.
• One deep-dive path beats shallow coverage of everything.
• Include failure mode: "if payment down, breaker opens, backup provider."

Anti-patterns to avoid

• Microservices for 100-user app in interview.
• Event sourcing for everything without read/write justification.
• Drawing 20 boxes in 45 minutes with no depth.

Common mistakes

• Forgetting to ask scale numbers — patterns depend on forces.
• No back-of-envelope capacity estimate.

Debugging tips

• If stuck, pick checkout — you know its pattern composition from this course.

Optimization strategies

• Memorize 3 compositions: checkout, notifications, URL shortener.

Common misconceptions

• System design ≠ no patterns — enterprise patterns ARE system design vocabulary.
• Not every box needs GoF name — Gateway/Saga/CQRS are the system design layer.

Advanced interview questions

Summary

You can compose and name patterns in 45-minute system design. Tell the payment platform offer story — if you can do that, you own System Design + Patterns.