Skip to content
L5 Prep

System design curriculum

At L5 this round carries roughly as much weight as all coding rounds combined. You are expected to drive it — the interviewer should mostly listen and probe.

This page is the curriculum — what to learn and what to practise. The system design reference is the depth behind it: every building block below explained with its tradeoffs, plus a skeleton for each of the 12 problems.

The 12 problems

Tick one only when you have run it end-to-end at the full 45 minutes, spoken. The Week 7 target is 10 of 12. Titles and focus areas are read from 03-system-design-curriculum.md.

Building blocks and papers covered0 / 0

Ticks are saved in this browser only.

At L5 this round carries roughly as much weight as all coding rounds combined. You are expected to drive: the interviewer should mostly listen and probe.

The 45-minute framework

Time-box it. Practice with a visible clock until the pacing is automatic.

Minutes Phase What you do
0–5 Scope Clarify. Who are the users? What’s in scope, explicitly out of scope? Nail down 3–5 functional requirements and 3–4 non-functional (scale, latency, availability, consistency, durability). Write them down.
5–10 Estimate DAU → QPS (avg and peak) → storage/day and /year → bandwidth. Round aggressively; say your assumptions out loud.
10–15 API + data model Define the 3–5 core endpoints with signatures. Define the primary entities and their access patterns. Access patterns drive the storage choice — say that explicitly.
15–30 High-level design Draw the boxes: clients → LB → services → storage/caches → async workers. Justify every component. Pick your storage and defend it.
30–40 Deep dive Interviewer will pick one, or you propose the most interesting: sharding scheme, hot keys, consistency, the fan-out strategy, the indexing approach. Go deep enough that the tradeoff is explicit.
40–45 Failures, scale, wrap Single points of failure, replication and failover, cache stampede, backpressure, rate limiting, monitoring/SLOs, multi-region. State what you’d do with more time.

The two most common L5 failures: (1) designing before scoping, (2) presenting a design with no tradeoffs. There is no correct answer — there is only a defended answer.

Building blocks (know cold, in your own words)

Networking & entry

  • DNS, anycast, CDN, edge caching
  • L4 vs L7 load balancing; health checks; consistent hashing for LB
  • API gateway: auth, rate limiting, request routing
  • Long polling vs SSE vs WebSockets — and when each is right

Storage

  • SQL vs NoSQL: pick based on access patterns and consistency needs, never on “scale”
  • B-tree vs LSM-tree — read-heavy vs write-heavy, compaction cost
  • Indexing: primary, secondary, composite, covering; why secondary indexes are hard when sharded
  • Object storage (blobs) vs block vs file
  • Time-series and columnar stores; when analytics needs a separate path

Distribution

  • Partitioning: range, hash, consistent hashing (+ virtual nodes); how to rebalance
  • Replication: leader-follower, multi-leader, leaderless (quorum, R + W > N)
  • Consistency: strong, eventual, causal, read-your-writes, monotonic reads
  • CAP and, more usefully, PACELC
  • Consensus: Raft/Paxos at the level of “leader election + replicated log”, plus what it costs you in latency
  • Distributed transactions: 2PC, sagas, outbox pattern, idempotency keys

Caching

  • Cache-aside vs write-through vs write-back
  • Eviction policies; TTL strategy
  • Invalidation, thundering herd, cache stampede (request coalescing, jittered TTL)
  • Hot-key mitigation: key splitting, local caches, replication of hot shards

Async & data flow

  • Message queues vs pub/sub vs log-based streaming (Kafka semantics: partitions, offsets, consumer groups)
  • Delivery semantics: at-most-once, at-least-once, effectively-once — and why exactly-once is a lie without idempotency
  • Batch (MapReduce) vs stream processing; windowing, watermarks, late data
  • Backpressure, dead-letter queues, retry with exponential backoff + jitter

Reliability & operations

  • SLI/SLO/error budgets
  • Circuit breakers, bulkheads, graceful degradation, load shedding
  • Rate limiting algorithms: token bucket, leaky bucket, sliding window
  • Observability: metrics, structured logs, distributed tracing
  • Blue/green and canary deploys; multi-region active-active vs active-passive; RTO/RPO

Estimation cheat sheet

Memorize these. Fluency here buys credibility in the first 10 minutes.

1 million DAU, 10 requests/user/day  →  ~116 QPS average
Peak                                 →  2–5× average
1 KB × 1M writes/day                 →  ~1 GB/day  →  ~365 GB/year
Seconds in a day        ≈ 86,400  (~10^5)
Seconds in a year       ≈ 3.15 × 10^7

Latency ballparks:
  L1 cache               ~1 ns
  Main memory            ~100 ns
  SSD random read        ~100 µs
  Network within DC      ~500 µs
  Disk seek (HDD)        ~10 ms
  Cross-continent RTT    ~150 ms

The 12 problems

Do each end-to-end at full 45 minutes, spoken. Weeks 5–6. 06-system-design-reference.md has a skeleton for each one — read it after your attempt, never before.

Tier 1 — foundational (do first)

  1. URL shortener — ID generation, base62, hot-key reads, cache, redirect latency
  2. Rate limiter — distributed counters, token bucket, Redis atomicity, accuracy vs cost
  3. Web crawler — politeness, frontier design, dedup at scale (bloom filters), traps
  4. Search autocomplete / typeahead — trie sharding, ranking, offline index build, latency budget

Tier 2 — the classics 5. News feed — fan-out on write vs read, the celebrity problem, ranking, pagination with cursors 6. Chat / messaging — WebSocket connection state, presence, ordering, delivery receipts, offline queue 7. Distributed cache — consistent hashing, replication, eviction, cluster membership 8. Video streaming (YouTube) — upload pipeline, transcoding fan-out, CDN, adaptive bitrate, metadata store

Tier 3 — Google-flavored 9. Google Drive / Dropbox — chunking, dedup, sync protocol, conflict resolution, delta sync 10. Distributed job scheduler — leader election, at-least-once execution, cron semantics, straggler handling 11. Metrics & monitoring system — ingestion at scale, time-series storage, downsampling, alerting (this is Monarch) 12. Ad click aggregator — stream processing, exactly-once counting, late/duplicate events, reconciliation with batch

Also plausible for Google specifically: Google Maps (routing, tile serving), Google Docs (collaborative editing/OT/CRDT), a distributed file system (GFS), Google Photos (storage tiering, ML pipeline).

Papers worth reading

Referencing these by name — and knowing the tradeoff each made — is a genuine differentiator at Google.

  • MapReduce — batch processing model, fault tolerance via re-execution
  • GFS — single-master design and why it was acceptable; chunk servers
  • Bigtable — LSM + SSTables, row-key design, why the schema is a sorted map
  • Spanner — TrueTime, external consistency, and what it costs
  • Chubby — lock service, why “Paxos as a service” beat libraries in practice
  • Dapper — distributed tracing with sampling
  • Optional: Borg (cluster scheduling), Monarch (time-series at scale)

Self-critique after every design

Score yourself honestly. Log it.

  • Did I scope before designing, or did I start drawing boxes immediately?
  • Did I estimate, and did the numbers actually change a decision?
  • Did I state a tradeoff for every major choice, or just assert it?
  • Did I name at least two failure modes and how the system handles them?
  • Did I go deep on at least one component, or stay shallow across all of them?
  • Was I driving, or was the interviewer pulling it out of me?