14 - System Design Interview Practice
This is the capstone track of the whole curriculum. Everything you built in the previous thirteen tracks — request/response, APIs, auth, the data layer, caching, background processing, search, observability, security, distributed-systems patterns, advanced API paradigms, testing, and devops — was a component. This track teaches you to assemble those components into whole systems on a whiteboard, under time pressure, the way a real system-design interview demands: estimate the capacity, scope a deliberately vague prompt, and drive a complete design through requirements, data model, architecture, a deep-dive on the genuinely hard part, and an honest accounting of the tradeoffs. It's less about learning new technology and more about synthesis and judgment — recognizing which of the patterns you already know applies, why, and what it costs.
How this track works
- It assumes you've worked through the earlier tracks — this is where their concepts get used, not re-taught. Modules cross-reference earlier tracks by name constantly (the idempotency-key pattern from 10-distributed-systems- patterns, cache-aside from 05-caching-and-performance, the inverted index from 07-search-with-elasticsearch, and so on) so you can see each piece slot into a larger design. You don't need to re-read those tracks first, but the cross-references will land harder if you have.
- Unlike the other tracks, this one is mostly prose, diagrams, and estimation math rather than heavy code — that's correct for system design. Where code clarifies a contract or an algorithm (a token-bucket rate limiter, a base62 encoder, an idempotent API), it's Python/FastAPI, but most of the work is reasoning, sketching architectures in ASCII, and doing back-of-envelope arithmetic out loud.
- The track builds deliberately: module 00 gives you the estimation math and 01 gives you the interview framework, and every problem module (02–07) then runs that framework on a canonical system, reinforcing the same seven steps until they're a reflex. Go in order; each problem assumes the vocabulary and habits of the ones before it.
- Each standard module has the same shape: why it matters, concepts, a command reference (formulas, checklists, and reference architectures for this track), progressive hands-on design exercises (do them — including a "diagnose and fix a flawed design" scenario each), an independent challenge with no solution, common mistakes, and a checkpoint quiz. Two cumulative reviews (in modules 03 and 06) mix questions from everything so far, closed-book.
- The last module is an open-ended capstone with no solution given — a full mock interview on a problem the track never worked directly — the integration test for the whole track and the whole curriculum.
Modules
| # | Module | What you'll be able to do | Time |
|---|---|---|---|
| 00 | Capacity estimation and back-of-envelope math | Estimate QPS, storage, bandwidth, and memory from a DAU figure using a repeatable recipe and a handful of memorized numbers, and turn every estimate into an architectural decision | 60-90 min |
| 01 | The system design interview framework | Run a structured seven-step whiteboard session — requirements, estimation, API, data model, high-level design, deep-dive, bottlenecks — and talk tradeoffs the way interviewers score | 60-90 min |
| 02 | Designing a URL shortener | Drive the full framework on a read-heavy storage problem: unique-id generation, cache-aside redirects, key-based partitioning, and the 301/302 tradeoff | 60-90 min |
| 03 | Designing a rate limiter | Design distributed rate limiting: token bucket vs. sliding window, atomic shared counters, race conditions, and fail-open vs. fail-closed — plus the first cumulative review | 75-100 min |
| 04 | Designing a distributed cache and key-value store | Design the storage substrate itself: consistent hashing, replication, quorum consistency (CAP made real), eviction policies, and write policies | 75-100 min |
| 05 | Designing a news feed or social timeline | Solve the fan-out problem: push vs. pull, the celebrity problem, the hybrid model, async fan-out, and feed caching at scale | 75-100 min |
| 06 | Designing a chat and notification system | Design real-time delivery: websockets and the connection layer, presence/routing, ordering, at-least-once delivery, store-and-forward, and multi-channel notifications — plus the second cumulative review | 75-100 min |
| 07 | Designing a video streaming or large-scale search system | Design two large-scale specializations: video (object storage, CDNs, transcoding, adaptive bitrate) and search (inverted index, relevance ranking, distributed scatter-gather query) | 75-100 min |
| 08 | Capstone project | Run a full mock interview on a payments/ledger system — a correctness-and-consistency-critical problem that synthesizes estimation, data modeling, idempotency, atomicity, and observability from across all 14 tracks | 4-6 hrs |
Start here → 00-capacity-estimation-and-back-of-envelope-math/README.md
Back to the master index: ../README.md
How to work through this
- Go in order. Modules 00 and 01 are the foundation — the estimation math and the framework — and every problem module (02–07) applies them. Skipping ahead to a problem before you own the framework means you'll drift into buzzword-listing, which is exactly the failure mode this track trains out of you.
- Do the exercises out loud. These are written and spoken design exercises, not code to run. Talk through them at a whiteboard (or to a rubber duck), narrate your reasoning, and time yourself — because that's the actual skill being built. Silent reading builds recognition; talking builds recall.
- Attempt every quiz question in writing before expanding the answer, and do each independent challenge with zero peeking. Struggling for 10-15 minutes before checking a hint is the point.
- Take the two cumulative reviews closed-book. They're in module 03 (mixing 00-03) and module 06 (mixing 00-06). If you can't answer something from three modules back, go redo that module's exercises.
- Before starting a new problem module, re-run the previous one cold — blank whiteboard, no notes, out loud, timed. Cold repetition is what turns the framework into the reflex you'll have in a real interview.
This is the final track of the 14-track backend engineering curriculum — there is no next track. Completing it means you've gone from how a single HTTP request travels from browser to backend all the way to designing complete distributed systems end to end on a whiteboard. From here, the work is practice and integration: re-run this track's designs cold, revisit the earlier tracks' capstones now that you can see each as a component inside a larger system, and take a real system you use or want to build and drive the full framework on it. You have the whole toolkit now — go build things.