System Design All-in-One Mental Map

Follow these 12 steps during the interview to cover every module. Each step maps to specific technology choices and tradeoffs.

Decision Mainline

1. Who is the client?
        ↓
2. How do they communicate?
        ↓
3. How does traffic enter the system?
        ↓
4. What does the API/service do?
        ↓
5. Sync or Async communication?
        ↓
6. Where does data live?
        ↓
7. Do we need cache?
        ↓
8. Do we generate events?
        ↓
9. Do we integrate external systems?
        ↓
10. What happens when something fails?
        ↓
11. How do we scale?
        ↓
12. How do we observe it?

1. Client Types

App (iOS / Android)
Web (Browser)
Server (internal service / third-party)

2. Communication Protocols

gRPC Tradeoff

Strong schema / high performance / HTTP/2 multiplexing. But poor browser support, harder to debug than JSON REST, higher tooling complexity.

3. Traffic Entry: Load Balancer

Requests pass through LB (commonly Nginx), distributed evenly to target services.

LB Algorithms

L4 vs L7

4. API Layer (Cross-Cutting Concerns)

├── Generate request_id / trace_id
├── Authentication & Authorization
├── Request-level logging & end-to-end metrics
├── Default timeout & rate limiting
├── Request validation & size limit
├── Routing
├── CORS
└── API versioning

5. Inter-Service Communication: Sync vs Async

Sync: gRPC

Used when you need an immediate result.

Async: Pub/Sub (Message Queue)

Used for decoupling, especially when the publisher receives continuous messages or has burst traffic the subscriber cannot handle.

Message Queue Selection

Pub/Sub Observability & Backpressure

Key metrics to monitor:

Producer rate
Consumer rate / lag / throughput
Queue depth / Oldest message age

Solutions when consumer lag is too high:

Scale consumers (if possible)
Batch consumption (if possible)
Slow producer (backpressure)
Reject low-priority work / load shedding (degradation)

Rate Limiter

Controls publisher speed, applies backpressure to upstream.

Common algorithms:

Fixed Window
Sliding Window
Sliding Window Counter (approximation)
Token Bucket
Leaky Bucket

Single-machine vs distributed (Redis atomic / Lua script).

6. Data Storage

DB Selection

RDBMS Core Knowledge

Write DB + Generate Event: Outbox + CDC

Prevents the problem where DB write succeeds but event publishing fails.

DB Transaction
├── Write business data
└── Write outbox table (same transaction)

CDC (Change Data Capture)
└── Monitor binlog / outbox table → Publish to Kafka

• Outbox: Write DB + write outbox table in the same transaction, ensuring reliable persistence
• CDC: Monitor transaction log / binlog, read events from outbox table and publish to Kafka
• The two are complementary. Can also skip CDC and use polling on the outbox table instead

Pagination

Static Files

Static files → Object Storage (S3)
             → CDN cache
             → HTML references CDN URLs

7. Cache

Selection

Common Cache Problems

Mnemonic:

Penetration = NONE exists
Breakdown   = ONE hot key
Avalanche   = MANY keys

Other Cache Considerations

• Staleness / Freshness: Define acceptable data delay
• Data Consistency: Cache must not be the source of truth
• Bloom Filter (Redis implementation): Bitmap to filter out non-existent IDs, avoiding invalid queries

8. External Service Integration

Adapter Layer

Dedicated layer to handle external service API / signature / request / response, plus data field and format conversion.

Ingestion Service

When receiving data from external sources:

├── Data normalization
├── Invalid data cleanup
├── Aggregation
└── Freshness check

Communication Methods

HTTP / WebSocket / Kafka are the three common choices.

How to protect yourself when downstream services fail?

Health Check (heartbeat + health API)
Retry + Exponential Backoff + Jitter
Timeout
Circuit Breaker (fail fast, avoid cascading failure)
Bulkhead (isolate connection pools, external hang does not affect other services)
Fallback
Idempotency
DLQ (Dead Letter Queue)
Reconciliation
Decouple: use Kafka to decouple upstream and downstream

9. File Upload

Client → API → Generate pre-signed URL (short-lived)
Client → Direct upload to Object Storage (bypass server)

10. Background & Reconciliation

Background reconciliation service to handle corner cases (e.g. stuck approval failures).

Reliability Patterns

How does my system fail safely?

All reliability patterns consolidated:

Idempotency

Retry is only safe when the operation is idempotent.

Client
   ↓ request_id
API
   ↓
Idempotency Store (check if already processed)

Use cases:

Payment
Order creation
Notification
MQ consumer
Webhook
Inventory deduction

Flash Sale

Normal traffic          Flash Sale
      ↓                       ↓
   5k QPS               500k QPS

Core challenge: How to absorb instant burst while protecting DB.

Typical Architecture

Client
  ↓
CDN / Gateway
  ↓
Rate Limiter
  ↓
Eligibility Check
  ↓
Redis Atomic Stock Reservation (Lua script for atomicity)
  ↓
MQ (peak shaving)
  ↓
Order Worker
  ↓
DB

Connected knowledge points:

Rate Limiter → throttling
Redis Lua → atomic inventory deduction
Idempotency → prevent duplicate orders
MQ buffering → peak shaving
Backpressure → control producer speed
Async order creation → asynchronous ordering
DLQ → failed order handling
Compensation / Reconciliation → auditing

Special Workload Quick Reference

Read-heavy

CDN
Cache
Read Replica
Denormalization

Write-heavy

Partition / Sharding
Batch writes
Async processing
Kafka
Cassandra / suitable storage

Real-time

WebSocket / SSE
Kafka
Stream Processing
Redis Pub/Sub

Large Fan-out

Feed (Timeline)
Notification
Celebrity problem
Fan-out on read vs Fan-out on write

Large File

Object Storage
Pre-signed URL
Multipart upload
CDN

Strong Consistency

DB Transaction
Pessimistic / Optimistic Lock
Version control
Idempotency

Burst Traffic

Rate Limiter
Queue buffering
Load Shedding
Autoscaling
Backpressure