System Design Layers

NFR answers tell you what the system needs. Layers are what you draw. Start with the core 4, then add layers based on what the interviewer tells you.

The Core 4 — Always Draw These

Every system design diagram starts here. Add more only when NFRs demand it.

Copy[Client]
   ↓
[Load Balancer]
   ↓
[App Server(s)]
   ↓
[Database]

Optional Layers — Added by NFRs

Add only when an NFR demands it — each one solves a specific problem but adds latency, cost, and operational complexity.

NFR → Layers to Add

Translate the interviewer's requirements directly into layers. Use this to build your diagram from the answers you've gathered.

Latency Reference — Cost Per Layer

Single source of truth for per-layer latency costs. Use the Typical column for estimates — Best Case shows the theoretical floor with everything going right.

Network is included: Each component figure (Redis 1ms, DB 5ms, etc.) covers the full round-trip including the internal network hop — App→component→App. The only network cost listed separately is the user-facing leg (Browser↔LB) because that varies by geography and is outside your control.

Scenario breakdowns below use the Typical column. Update this table to recalibrate all scenarios.

Same order, left to right (typical values):

Copy                                                                    ┌─(1ms)──► Redis
Browser ─(20ms)─► CDN ─(1ms)─► LB ─(10ms)─► API GW ─(5ms)─► App ─┼─(5ms)──► DB
                                                                    ├─(3ms)──► Kafka
                                                                    └─(50ms)─► S3

Scenario 1: Read-Heavy

Design Twitter feed, Reddit homepage, YouTube video page.

NFRs that triggered this: high scale, read-heavy, low latency

Copy[Client]
   ↓
[CDN] ──────────────────→ (cache hit: return static assets / cached response)
   ↓ (miss)
[Load Balancer]
   ↓
[App Servers]
   ↓
[Cache (Redis)] ─────────→ (cache hit: return feed)
   ↓ (miss)
[DB Primary] + [DB Read Replicas]  ← writes go to primary, reads go to replicas

Latency breakdown:

Key decisions:

• Feed data is precomputed and stored in Redis. App servers read from cache, not DB.
• CDN handles profile images, thumbnails, static JS/CSS.
• Read replicas absorb the bulk of DB traffic.

Scenario 2: Write-Heavy

Design an analytics pipeline, logging system, IoT sensor ingestion.

NFRs that triggered this: high scale, write-heavy, fault tolerance

Copy[Client / Producers]
   ↓
[Load Balancer]
   ↓
[App Servers]  ← accept writes, validate, publish to queue
   ↓
[Message Queue (Kafka / SQS)]  ← absorbs bursts, durable buffer
   ↓
[Workers / Consumers]  ← process at own pace, retry on failure
   ↓
[Database / Data Warehouse]

Latency breakdown:

Key decisions:

• App servers never write directly to the DB — they publish to the queue and return 200 immediately.
• Queue decouples ingestion speed from processing speed. If workers are slow, queue grows but nothing drops.
• Workers can be scaled independently. Failed jobs stay in queue for retry.

Scenario 3: Strong Consistency Required

Design a payment system, hotel booking, airline seat reservation.

NFRs that triggered this: strong consistency, durability, security

Copy[Client]
   ↓
[Load Balancer]
   ↓
[API Gateway]  ← auth, rate limiting, fraud checks
   ↓
[App Servers]
   ↓
[DB Primary]  ← all reads AND writes go here (no replicas on write path)
   ↓ (synchronous)
[DB Standby]  ← hot standby, promoted on failure
   ↓
[Audit Log]  ← append-only record of every transaction

Latency breakdown:

This is the cost of strong consistency. You're paying ~30ms extra vs an async write to guarantee no data loss.

Key decisions:

• No cache on the write path — stale reads could cause double-booking or double-charging.
• DB standby is synchronous (primary waits for standby to confirm before acking write).
• API Gateway handles rate limiting to prevent abuse at the payment endpoint.
• Audit log is append-only and separate — required for compliance and debugging.

Scenario 4: Low Latency

Design autocomplete/typeahead, live leaderboard, stock price feed.

NFRs that triggered this: latency < 100ms, read-heavy, high scale

Copy[Client]
   ↓
[CDN / Edge Cache] ──────→ (return if result cached at edge)
   ↓ (miss)
[Load Balancer]
   ↓
[App Servers]
   ↓
[Cache (Redis)] ──────────→ (precomputed results — return immediately)
   ↓ (cold start / miss only)
[Database]

Latency breakdown:

At < 100ms target, even a DB miss is within budget — but only if the query is indexed. The goal is 99%+ Redis hit rate so DB is never on the hot path.

Key decisions:

• DB is off the hot path entirely. Cache must have near-100% hit rate for common queries.
• Results are precomputed and pushed into Redis (e.g., top 10 autocomplete results per prefix).
• CDN caches at the edge for global users — reduces round-trip time before even hitting your servers.
• Any update to results is pushed into Redis asynchronously, not on the request path.

Scenario 5: Balanced / General Purpose

Design Uber, Airbnb, a general marketplace.

NFRs that triggered this: moderate scale, availability, latency, some consistency

Copy[Client (Web + Mobile)]
   ↓
[CDN]  ← static assets only
   ↓
[Load Balancer]
   ↓
[API Gateway]  ← auth, rate limiting
   ↓
[App Servers]
   ├──→ [Cache (Redis)]   ← hot reads (search results, listings)
   ├──→ [Message Queue]   ← async tasks (email, notifications, billing)
   │         ↓
   │     [Workers]
   ↓
[DB Primary] + [DB Read Replicas]
   ↓
[Object Storage (S3)]  ← user photos, listing images

Latency breakdown:

Key decisions:

• Most features read from cache, write to DB. A few critical paths (booking, payment) skip cache and write directly to primary.
• Message queue handles notifications, confirmation emails, and analytics events — nothing that should block the user's request.
• Object storage for all media. App servers only store the URL reference in the DB.

Quick Cheat Sheet

One-line trigger for every optional layer — use this at the end of requirements gathering to sanity-check your diagram.

CopyAlways:        Client → Load Balancer → App Server → Database

Add CDN        when: global users, latency matters, lots of static assets
Add Cache      when: read-heavy, same data read repeatedly, latency < 100ms
Add Queue      when: write-heavy, async work, need to absorb bursts
Add Workers    when: you added a queue
Add API GW     when: auth + rate limiting needed at entry point
Add Replicas   when: read-heavy or high availability required
Add Object     when: files, images, video, blobs
Storage