Most system design prep is unstructured grazing — a walkthrough here, a blog post there, no sense of what’s foundational and what’s a variant. This plan sequences this site’s system design library into nine weeks, in dependency order: vocabulary first, anchor questions second, the product systems you’re most likely to be asked third, specialized questions last. Infrastructure primitives — “design your own key-value store / queue / lock” — are pulled into an optional deep-dive track for loops that actually probe them. Every week tells you what to read, what to practice, and how to know you’re done.
Who this is for
A backend software engineer with system design rounds coming up in the next one to three months, targeting senior IC roles:
- Google L5
- Meta E5
- Amazon L6
- Senior SWE at Stripe, Datadog, Airbnb, and similar companies
You’ve worked on real backend systems but haven’t necessarily designed one from a blank whiteboard, and your last exposure to “design Twitter” may have been a video you half-watched. This plan assumes the interview matters enough to spend ~6 focused hours a week for 9 weeks.
What senior system design interviews measure
A senior system design interview is not a distributed systems exam. Interviewers are evaluating whether you can:
- Clarify ambiguous requirements — ask the right questions before drawing anything; identify the 1–2 constraints that shape the design.
- Translate requirements into capacity assumptions — estimate load, storage, and bandwidth; let the numbers drive architecture decisions.
- Make deliberate tradeoffs — choose between alternatives and defend the choice by naming what you’re sacrificing.
- Identify bottlenecks and failure modes — what breaks first, how you detect it, how you recover.
- Design for operations and change — deployment, monitoring, rollback, migration, and what evolves at 10× scale.
- Communicate decisions under time pressure — structure a 45-minute conversation, calibrate depth to interviewer signals, and drive without being led.
The goal is not perfect architecture. The goal is sound engineering judgment, made visible.
Important
Key takeaway: A senior system design interview scores judgment made audible, not architecture drawn perfectly. Every week below trains one slice of that judgment; the colored callouts are the skimmable layer — the red Challenge yourself questions to test yourself against, and the accent callouts flagging the traps and signals that decide the round.
System design rubric
What interviewers score, whether or not they use a formal rubric:
| Signal | 0 (Concern) | 1 (Below bar) | 2 (Meets bar) | 3 (Strong hire) |
|---|---|---|---|---|
| Requirements | Misses key requirements; starts drawing immediately | Asks few questions; accepts problem as stated | Covers functional and non-functional; identifies scope | Prioritizes, reframes, and identifies the hard sub-problem |
| Estimation | None | Weak or hand-waved | Mostly reasonable; drives at least one decision | Numbers shape the architecture; explains what changes if 10× |
| Architecture | Fragmented; boxes without relationships | Workable but generic | Coherent; components justified | Deliberate tradeoffs; phased evolution; non-obvious insights |
| Distributed systems | Shallow; names technologies without understanding | Partial; one or two concepts applied | Competent; correct application of replication, partitioning, consistency | Deep and pragmatic; handles follow-ups without hesitation |
| Operations | Absent | Basic (“add monitoring”) | Solid; names SLOs, failure detection, deployment | Production-first; discusses canary, rollback, migration, observability |
| Communication | Disorganized; interviewer drives | Acceptable; follows prompts | Structured; narrates tradeoffs; checks understanding | Drives the conversation; calibrates depth; uses hints productively |
Most senior candidates fail because one category stays at 0–1 while the others are fine. The rubric tells you where to focus: score yourself after every mock and invest in the dimension that’s dragging.
Company calibration
System design rounds vary more across companies than coding does:
| Company | Design focus | What they probe hardest | Bias your prep toward |
|---|---|---|---|
| Meta E5 | Product architecture at scale | Tradeoffs, speed of iteration, move-fast signal | Weeks 2, 3, 7, 8 — product-facing questions, ranking, real-time |
| Amazon L6 | Ambiguity and operations | Operational thinking, failure handling, LP alignment in design decisions | Weeks 5, 6, 8 — transactions, streaming pipelines, failure modes |
| Google L5 | Distributed systems fundamentals | Consistency, replication, correctness arguments | Weeks 1, 4 + infra deep-dive track — vocabulary precision, AP core, then the CP database and lock from scratch |
| Stripe | Reliability, APIs, consistency | Exactly-once semantics, idempotency, data integrity, API contract design | Weeks 4, 5 + queue deep-dive — storage, transactions/idempotency; extended reading mandatory |
| Datadog | Observability and scale | Time-series storage, cardinality, pipeline reliability | Weeks 6, 7 + queue deep-dive — streaming, metrics/monitoring, aggregation |
| Snowflake | Storage engines, query systems | Partitioning, query planning, storage-compute separation | Weeks 4, 7 + database deep-dive — distributed storage, the CP database, data pipelines |
| Other companies | Varies | Find their differentiator | Match weeks to their focus area |
Tip
How to use this: In week 0, identify your targets and bias your depth hours toward the “probe hardest” column. The weekly plan is still the spine — but you spend extra time on the weeks that map to your company’s emphasis.
What you should already know
This plan starts at distributed systems, not at zero. Before week 1, you should be comfortable with:
- HTTP and APIs. Request/response, status codes, what REST roughly means, JSON payloads. You’ve built or consumed APIs at work.
- One database, used in anger. You’ve designed tables or documents, written real queries, and met at least one slow query you had to fix. You know what an index is and roughly why it helps.
- What a cache is and why it exists. You’ve used Redis or memcached, or at least an in-process cache, and you’ve been bitten by stale data once.
- What a message queue is for. You can say why work is moved off the request path, even if you’ve never operated Kafka.
- Big-O instincts. Not interview-grade algorithms — just the reflex that scanning 100M rows per request is different from reading one.
- One production war story. Something you built, broke, or fixed that you can describe for five minutes without notes. The interview will use it; so will this plan.
If two or more of these are shaky, spend a week or two closing those gaps first — this plan builds on them immediately.
What you do not need: prior distributed systems theory, experience at “web scale,” or having read any of the classic papers. The plan covers that.
How the weekly plan works
Three rules that make the hours count:
- Attempt before reading. For every walkthrough marked practice first, set a 25-minute timer and design the system yourself — out loud, on paper or a whiteboard — before opening the article. Then read it as a gap analysis of your attempt. Reading first turns walkthroughs into bedtime stories; attempting first turns them into coaching.
- Out loud means out loud. The interview is spoken. Practice narrating your clarifying questions, your capacity math, and your tradeoffs to an empty room. It feels ridiculous for exactly two sessions.
- One notebook page per system. After each walkthrough, write the system’s one core tension and one hidden trap from memory, in two sentences. By week 9 this page is your review sheet.
~6 hrs/week ≈ two reading blocks and one practice block. The plan scales: 5 weeks at 11 hrs/week works; 18 weeks at 3 hrs/week works. Don’t reorder the weeks — later ones lean on earlier vocabulary.
Tip
How to use the “Challenge yourself” questions: Every week ends with a red Challenge yourself callout — a set of probing questions to think about. Use them three ways: as a self-check (can you answer each out loud, from memory, without notes?); as discussion starters with a mock partner or coach when something felt shaky; and as a preview of the follow-up questions a real interviewer escalates to once your main design lands. If a question stumps you, that’s the signal for where to re-read — not a reason to move on.
The weekly plan
Week 1 — Vocabulary, estimation, and the warm-up
The concepts that appear in every question — partitioning, capacity math, failure patterns, operational vocabulary — plus the classic warm-up walkthrough to apply them on immediately. This week builds the shared language everything else depends on, then lands it on the gentlest question in the set.
Read:
- Framework: Thinking About Tradeoffs in System Design — the reasoning process (axes → context → cost). Read this for how to decide.
- Reference: Common System Design Decisions — its companion cheat-sheet: the default choices and when to switch. Skim now, return to it before the loop for fast review.
- Reference: Capacity Estimation
- Reference: Partitioning Strategies
- Walkthrough: Designing a URL Shortener — the classic warm-up: read-heavy caching, ID generation correctness. Practice first; it’s short enough to attempt and read in one block, and it turns week 1’s vocabulary into a concrete first design.
Warning
Failure vocabulary. These are the patterns behind every “what if…?” follow-up. Know the name, the mechanism, and one real-world trigger for each:
- Retry storms — cascading retries amplify load after partial failure
- Thundering herd — coordinated cache miss or reconnection
- Hot partition — traffic skew concentrates on one shard
- Cascading failures — one overloaded service takes down its dependents
- Split brain — network partition causes two leaders
- Backpressure — producer overwhelms consumer; queue growth is the symptom
- Poison messages — one bad message blocks an entire consumer group
Tip
Operational vocabulary. The language of production — interviewers use these to probe whether you’ve actually run systems:
- SLI / SLO / SLA — signal, objective, agreement; know the hierarchy
- p50 / p95 / p99 — why tails matter more than averages
- Error budget — how much unreliability you’re allowed before freezing releases
- Canary deploy — gradual rollout to detect regressions before full traffic
- Circuit breaker — fail-fast when a dependency is down
- Idempotency — safe to retry without side effects
- Rollback — reverting a bad deploy; know the difference between code rollback and data rollback
Practice: run the capacity-estimation method on three products you use (a chat app, a photo app, a ride app) — QPS, storage, read/write ratio, and the design conclusion each number forces. Ten minutes each, out loud.
You’re done when: you can do the 1M/day ≈ 12/sec arithmetic without paper, walk the URL shortener’s read path from memory, and name 5 failure patterns with their triggers from memory.
Note
Challenge yourself:
- You estimate 1M writes/day. Walk that to writes/sec out loud — and name one design decision that number changes.
- A read/write ratio of 100:1 vs 1:1 — how does each push your architecture in a different direction?
- Pick three failure patterns from the list. For each, name the mechanism and one real-world trigger.
- What’s the difference between a retry storm and a thundering herd? They look similar — what distinguishes them?
- In the URL shortener, why is caching so effective here specifically? What property of the data makes invalidation a non-problem?
- SLI vs SLO vs SLA — say the hierarchy in one sentence. Why do interviewers care that you know the difference?
- Why does p99 latency matter more than average for a user-facing service? When would you not care about the tail?
Week 2 — The anchor walkthrough and the data-layer vocabulary
The foundation question (News Feed), plus the replication/consistency/schema references it forces you to reason about. Everything later refers back to this week.
Read (practice first on the feed):
- Walkthrough: Designing a News Feed — the foundation: fan-out, the celebrity problem, ranking, capacity-driven architecture. Read it twice; its structure is the template for how you should walk any question.
Supporting references:
- Reference: Replication Strategies
- Reference: Consistency Models
- Reference: SQL vs NoSQL Schema Design
- Reference: Database Indexing — B-Tree vs LSM-Tree and composite-index column ordering; the near-universal follow-up once you name a database. Picks up where SQL-vs-NoSQL stops.
- Reference: Cache Access and Invalidation Patterns
- Reference: NoSQL Hot Key Mitigation Patterns
You’re done when: you can draw the hybrid push/pull feed from memory, explain why the follower-count distribution — not the average — decides it, state the difference between leader-follower and leaderless replication in two sentences each, and answer “how would you index this?” with B-Tree vs LSM-Tree and composite-column ordering.
Note
Challenge yourself:
- Why does the distribution of follower counts — not the average — decide push vs pull? What breaks if you design for the average?
- Walk the hybrid feed: which users get push, which get pull, and how do the two merge at read time?
- Leader-follower vs leaderless replication — two sentences each. When would you reach for each?
- You picked a database for the feed. The interviewer asks “how would you index this?” — B-Tree or LSM-Tree, and why?
- You have a composite index
(user_id, created_at). Which queries does it serve, and which does it not? - Where would strong consistency actually hurt the feed? Where is eventual consistency fine?
- A celebrity with 100M followers posts. Trace the write path — where does the cost land, and how does hybrid bound it?
Week 3 — Real-time systems
The highest-frequency interview cluster after feeds: connections, delivery, limits, and live location.
Read (practice first on chat and rate limiter):
- Walkthrough: Designing a Chat System
- Walkthrough: Designing a Notification System
- Walkthrough: Designing a Rate Limiter
- Walkthrough: Designing a Geospatial Matching System — the Uber/Yelp “nearby” question: geohash indexing, a high-QPS location firehose, and the boundary problem. A distinct question family that doesn’t reduce to any of the others; a favorite at ride-share and delivery companies.
Supporting references:
You’re done when: you can explain WebSocket vs SSE vs long-poll with a use-case for each, walk the token bucket algorithm with a worked example (capacity, refill, what the 101st request sees), and explain why a geohash proximity query must scan 9 cells, not 1.
Note
Challenge yourself:
- WebSocket vs SSE vs long-poll — give a use case where each is the right call.
- Walk the token bucket algorithm with numbers: capacity 100, refill 10/sec — what does the 101st request in one second see?
- In chat, how do you guarantee per-conversation message ordering when a user has two devices?
- Why must a geohash proximity query scan 9 cells, not 1? What’s the bug if you scan only 1?
- Rate limiting across many nodes — how do you count correctly without a single bottleneck?
- For the geospatial system, why is the location-update rate the real load, not the query rate?
- A rider and driver are matched simultaneously by two requests — how do you prevent a double-match?
Week 4 — Distributed storage and the consistency spectrum
The single highest-leverage week: the KV store introduces the vocabulary (consistent hashing, quorums, replication mechanics) that every later system leans on — kept as a “build the primitive” exercise because nothing else forces you to reason about quorums and conflict resolution from first principles. Then you apply that vocabulary to a real product, where the same ideas show up as sync and dedup rather than academic quorum math.
Read (practice first on the file storage service):
- Walkthrough: Designing a Distributed Key-Value Store — consistent hashing, quorums, vector clocks, hinted handoff. The single highest-leverage article in this plan. This is the AP end of the spectrum — availability and partition tolerance over strong consistency. Read it twice if anything feels shaky; every later system leans on this vocabulary.
- Walkthrough: Designing a File Storage & Sync Service — chunking, content addressing, delta sync, dedup, conflict handling. The KV store’s replication and conflict vocabulary, now applied to a product people actually use — a common Dropbox/Drive-style interview question.
Supporting reference:
You’re done when: you can do quorum arithmetic (what R+W>N buys and doesn’t), walk a conflict through vector clocks, explain what virtual nodes fix, and say how delta sync detects and resolves a concurrent edit.
Note
Challenge yourself:
- What does R + W > N actually buy you? Give an example where it still returns stale data.
- Walk a write conflict through vector clocks — how do you detect concurrent writes, and who resolves them?
- What problem do virtual nodes solve that plain consistent hashing doesn’t?
- What is hinted handoff, and what failure does it paper over?
- In file sync, how does delta sync detect that two clients edited the same file concurrently — and how do you resolve it?
- The KV store is AP. Name a requirement that would force you off it toward a CP design.
- Why is a partitioned system’s secondary index the thing that quietly creates a hot shard?
Week 5 — Transactions and correctness under contention
The application cluster interviewers reach for when they want to see whether you can hold a system correct under concurrency, not just fast. Both questions are strong-consistency (CP) problems wearing product clothing — the counterpart to week 4’s AP storage. A senior signal is recognizing when a problem demands strong consistency and reaching for the right mechanism rather than bolting one on.
Read (practice first on both):
- Walkthrough: Designing an Order Processing System — saga orchestration, idempotency, inventory reservation, payment compensation. Distributed transactions in the wild: how you keep a multi-step workflow correct when any step can fail.
- Walkthrough: Designing a Flash Deal System — inventory contention, oversell prevention, surge handling, degradation. The purest “strong consistency under extreme write contention” question in the set.
Supporting reference:
- Reference: Queue Delivery Semantics — at-least-once and idempotency are the backbone of both designs.
You’re done when: you can walk a saga with its compensation path, say where at-least-once delivery’s failure window lives and why idempotency closes it, and explain two distinct ways to prevent oversell and what each costs.
Note
Challenge yourself:
- Walk a saga end-to-end with its compensation path. What happens if the compensation itself fails?
- Where exactly does at-least-once delivery’s duplicate window live, and how does idempotency close it?
- Give two distinct ways to prevent overselling inventory — and what each one costs.
- Why not just use a distributed transaction (2PC) across services? What does the saga buy you instead?
- What makes an operation idempotent? Design an idempotency key for “charge this payment.”
- Under a flash-sale spike, what do you shed or degrade first — and what must stay correct no matter what?
- Two customers race for the last item. Trace the requests — who wins, and how is the loser told cleanly?
Week 6 — Streaming and aggregation pipelines
The async, high-throughput cluster: how systems ingest firehose-scale events, aggregate them correctly, and stay operable. This is where queue and stream-processing vocabulary lands in applied form — windowing, exactly-once, backpressure, and cardinality as a first-class capacity limit.
Read (practice first on the ad-click aggregator):
- Walkthrough: Designing an Ad Click Aggregation System — ingestion, streaming windows, exactly-once semantics, anti-entropy. The applied home of queue and stream semantics: consumer groups, ordering, and backpressure in service of a real aggregation pipeline.
- Walkthrough: Designing a Metrics & Monitoring System — time-series modeling, ingest at millions of samples/sec, cardinality, downsampling, alerting.
Supporting reference:
You’re done when: you can explain how a streaming window achieves exactly-once under retries, say where at-least-once delivery’s failure window lives and why idempotency closes it, and name cardinality as the metrics system’s real capacity limit.
Note
Challenge yourself:
- How does a streaming window produce exactly-once counts when events get retried?
- Tumbling vs sliding vs session windows — when does each fit?
- A late event arrives after its window closed. What are your options, and what does each cost?
- Why is cardinality — not raw event volume — the real capacity limit of a metrics system?
- Consumer lag is growing. Walk the diagnosis: is it a slow consumer, a hot partition, or backpressure — and how do you tell?
- Why does partition key choice decide whether you can parallelize consumers and keep ordering?
- A poison message is stuck at the head of a partition. What happens downstream, and how do you recover?
Week 7 — Search, ranking, and data pipelines
The read-side intelligence cluster: how systems find, rank, and count things.
Read (practice first on search and recommendation):
- Walkthrough: Designing a Post Search System
- Walkthrough: Designing a Recommendation System — the recall/ranking funnel; pairs with week 2’s feed.
- Walkthrough: Designing a Top K System — Count-Min Sketch and heavy hitters; its streaming windows deepen week 6’s aggregation pipeline.
You’re done when: you can explain why recommendation needs a funnel (the latency arithmetic), and what an inverted index is concretely enough to re-implement a toy one.
Note
Challenge yourself:
- Explain the recall → ranking funnel with the latency arithmetic. Why can’t you just rank everything?
- What is an inverted index, concretely? Sketch the structure for three short documents.
- Recommendation and news feed both rank — what’s genuinely different about the two problems?
- How do you keep a search index fresh when documents change constantly? What’s the freshness/cost tradeoff?
- Top-K over a firehose — why won’t a sorted set scale, and what does Count-Min Sketch trade for the savings?
- How do you shard a search index — by document or by term — and what does each cost at query time?
Week 8 — Delivery, and mock practice
The large-scale delivery questions, then a shift in mode: from learning to performing.
Read (practice first on video streaming):
- Walkthrough: Designing a Video Streaming Platform — upload pipeline, ABR transcoding, CDN delivery; a composition of the storage and delivery vocabulary from earlier weeks.
- Walkthrough: Designing a CDN
Then two full mock runs — 45 minutes each, out loud, no peeking, then read the walkthrough as your debrief:
- Walkthrough: Designing a Collaborative Editor — OT vs CRDT, presence, offline editing.
- Walkthrough: Designing a Distributed Job Scheduler — cron, delay queues, DAG orchestration, the tick problem at scale.
These two are composition questions — they test whether weeks 1–7 assembled into judgment. That’s why they’re mocks, not reading.
Mock pacing rubric (use this for every 45-minute mock):
| Phase | Time | What you’re doing |
|---|---|---|
| Requirements | 5 min | Clarify scope, identify the hard sub-problem, state non-functional constraints |
| Estimation | 5 min | QPS, storage, read/write ratio; name the number that shapes the design |
| Architecture | 20 min | Components, data flow, core tradeoff choice with defense |
| Deep dives | 10 min | Go 2–3 levels deep on the hardest component; handle follow-ups |
| Failure & operations | 5 min | Failure modes, detection, recovery, deployment |
You are not practicing diagrams. You are practicing pacing. Most candidates spend 35 minutes on architecture and rush the last 10 — which is exactly where senior signals live (depth, failures, operations). If your mocks consistently run out of time before failure modes, compress architecture by 5 minutes next time.
You’re done when: both mocks reached a complete design — requirements through failure modes — inside 45 minutes, even if imperfect.
Note
Challenge yourself:
- Video upload: walk the pipeline from raw file to something a phone can stream. Where does transcoding sit and why is it async?
- What does adaptive bitrate actually adapt to, and where does that decision get made?
- CDN cache invalidation — why is it hard, and what’s your strategy for a file that just changed?
- Collaborative editor: OT vs CRDT — what’s the core tradeoff, and which would you pick for offline editing?
- Job scheduler: how do you guarantee a job runs exactly once at its scheduled time across a fleet of workers?
- In your mock, where did you overspend time — and which senior-signal section got rushed as a result?
Week 9 — Integration and taper
Consolidation, the AI-era differentiators if they’re relevant to your loops, and rest.
- Re-read your notebook page (one tension + one trap per system). This is now your entire review surface — resist re-reading full articles.
- Run one final mock from a question you haven’t seen: Designing an Auction System or Designing a Full Ranking System.
- If your target companies are AI-adjacent, read two of: LLM Serving, RAG System, Vector Database, Agent Orchestration.
- Two days out: Guide: Last-Minute System Design Review Checklist and Guide: Managing Energy During Interview Loops.
You’re done when: the checklist reads like confirmation, not news.
Note
Challenge yourself:
- Pick any two systems you studied. What core tension do they share, and where do their solutions diverge?
- An interviewer asks a “what if” you’ve never seen. Walk the follow-up ladder out loud on it.
- Name one system where you’d switch consistency models mid-design — and the trigger that forces the switch.
- If AI-adjacent: why does LLM serving batch requests, and what does continuous batching change?
Infrastructure deep-dives (optional track)
Some loops ask you to build the primitive itself — “design a key-value store,” “design Kafka,” “design a distributed lock.” These are the deepest distributed- systems questions in the set, and they’re where consistent hashing, quorums, consensus, and fencing live in their purest form. But they’re not the median senior interview: most companies ask product systems (feed, chat, order processing) and probe the infra concepts through them. So these are fenced into their own track rather than the weekly spine.
Do this track if your loop is infrastructure- or storage-team-focused (Google, database/storage/platform orgs, or any JD that names “distributed systems” as the core competency). Skip it if you’re interviewing for product or application teams — the weekly plan already exercises these concepts in applied form, and the week-4 KV store is enough vocabulary for the follow-ups you’ll actually get.
Slot one or two of these in place of a lighter week, or add them as extra practice blocks. Each is a practice-first walkthrough like the rest.
- Walkthrough: Designing a Distributed Database — ranges + Raft, distributed transactions over consensus, MVCC. The CP mirror of the week-4 KV store: same fork, opposite contract. The single most valuable deep-dive if you have time for only one.
- Walkthrough: Designing a Distributed Queue — log vs queue semantics, partitioned ordering, consumer groups, replay, backpressure. Deepens week 6’s aggregation pipeline into its underlying engine.
- Walkthrough: Designing a Distributed Lock — fencing tokens, leader election; the GC-pause timeline is a reusable answer to many “what if it’s slow, not dead?” probes.
- Walkthrough: Designing a Distributed Cache — lighter read; reuses the KV store’s hashing and eviction vocabulary directly.
- Walkthrough: Designing a Rate Limiter — if you skipped it in week 3, the distributed-counter and multi-tenant sections are a compact infra deep-dive on their own.
You’re done when: you can design the week-4 KV store’s CP mirror (the database) from a blank page, and argue queue-vs-log from requirements.
Milestones at a glance
| After week | You can |
|---|---|
| 1 | Run capacity math out loud; walk the shortener from memory; name partitioning options; list 5 failure patterns and their triggers |
| 2 | Walk the feed from memory; name replication/consistency options; structure any question like the walkthroughs do |
| 3 | Pick and defend a connection model and a rate-limiting algorithm; run a 9-cell geohash proximity query |
| 4 | Do quorum arithmetic; walk a vector-clock conflict; explain virtual nodes; say how delta sync resolves a concurrent edit |
| 5 | Walk a saga with compensation; explain why idempotency closes the retry window; prevent oversell two ways |
| 6 | Explain exactly-once under retries; name cardinality as the metrics limit |
| 7 | Derive the recall/rank funnel; sketch an inverted index |
| 8 | Complete a cold 45-minute design, twice, within the pacing rubric |
| 9 | Review from one notebook page; walk in rested |
How to answer follow-up questions
Most candidates handle the main design fine. Follow-ups are where senior interviews are won or lost. Interviewers escalate to probe judgment — and most candidates freeze or give shallow “add more servers” answers.
Important
Key takeaway: The follow-up ladder below is the single most reusable tool in this plan — it turns any “what if…?” you’ve never seen into a structured, senior-sounding answer. It’s also the pattern behind every week’s red Challenge yourself questions: they’re follow-ups in disguise.
The follow-up ladder (use this pattern for any “what if” question):
- Clarify the failure. Restate what’s breaking and at what scale.
- State the tradeoff. Name what you’d sacrifice to fix it.
- Propose a change. Specific: what component, what mechanism.
- Explain the new costs. What does this fix break or make harder?
- Name the metric you’d watch. How would you know it’s working?
Example follow-ups and how to apply the ladder:
- “What if a celebrity posts?” → Fan-out write becomes hot partition (1) → trade write latency for read latency (2) → switch to pull-based for high-follower accounts (3) → read path is now slower for celebrity followers (4) → watch feed-render p99 for celebrity followers (5).
- “What if Kafka lags by 2 hours?” → Consumers can’t keep up, queue depth growing (1) → trade processing order for throughput (2) → scale consumer group, add backpressure on producers (3) → may process some events out of order (4) → watch consumer lag metric and end-to-end latency (5).
- “What if one region goes down?” → All traffic in that region is lost (1) → trade consistency for availability during failover (2) → async replication to standby region, DNS failover (3) → may serve stale reads during switchover (4) → watch cross-region replication lag and error rate during failover (5).
The pattern works because interviewers are testing judgment process, not memorized answers. A structured response — even to a question you haven’t seen — signals senior-level thinking.
Production thinking
Every system design answer should eventually address how you’d actually run the thing. This is the dimension that separates “good architecture on paper” from “I’ve actually operated distributed systems.” Weave these throughout your design, not as an afterthought:
- How do you deploy it? Canary → percentage rollout → full. What’s the blast radius of a bad deploy? How long until you detect it?
- How do you monitor it? What SLIs matter? Where do you set the SLO? What dashboard would you build first?
- How do you know it’s broken? Alerting on symptoms (error rate, latency) not causes. What’s the on-call runbook entry?
- How do you roll it back? Code rollback is easy. Data rollback is hard. Schema migrations are harder. Name which category your change falls in.
- How do you migrate data? Dual-write, backfill, shadow traffic, cutover. What’s your compatibility window? How do you validate?
- How do you recover from operator mistakes? Soft deletes, audit logs, point-in-time recovery. What’s the blast radius of a bad manual command?
Senior backend ≠ architecture artist. Senior backend = systems owner. Interviewers who’ve operated production systems can instantly tell whether you have too.
Common failure modes
Caution
Common mistake: Every pattern below is a way of substituting motion for progress — reading instead of practicing, memorizing instead of internalizing, diving deep instead of finishing. If one of these describes your last two weeks, the fix is in the pattern’s own line.
- The completionist. Reads all 25 walkthroughs, practices none, and discovers in the interview that recognizing a good design and producing one are different skills. The fix is mechanical: timer, blank page, out loud, then read.
- The memorizer. Learns the News Feed answer as a script, then meets “design a notification system for a hospital” and has no script. The walkthroughs teach a procedure — requirements, estimate, core choice, failure modes — not answers. Practice the procedure on unfamiliar questions; that’s what week 8 is.
- The depth diver. Disappears into the infrastructure deep-dive track reading Raft implementations and arrives at week 8 never having finished a full design in 45 minutes. Interview depth is bounded; breadth-with-judgment beats depth-in-one-corner. The deep-dive track and the extended reading are both fenced off from the weekly spine precisely so they can’t eat it — enter them only if your loop actually demands that depth.
- The silent designer. Practices everything in their head, performs fluently there, then stumbles narrating under observation. Speech is the deliverable; train the deliverable.
- The estimate skipper. Jumps to boxes and arrows, gets asked “how many servers?”, and improvises badly. Week 1 exists because the estimate is what makes every later choice defensible — it’s two minutes that buys authority for the next forty.
- The operations-blind architect. Draws a beautiful architecture, then can’t answer “how would you deploy this?” or “what metrics would you watch?” Gets flagged as lacking production depth. The production thinking section exists because this is the most common silent failure at senior level.
Extended reading
The best primary sources online, mapped to the week they deepen. Each earns its place by being something interviewers themselves have read.
Foundations (weeks 1–2)
- Latency numbers every programmer should know — the interactive version. Internalize the RAM/SSD/network ratios; they’re the constants in every capacity estimate.
- Notes on Distributed Systems for Young Bloods — Jeff Hodges. The mindset shift (“failure is the steady state”) in one essay; the best pre-read for everything that follows.
- Timelines at Scale — Twitter’s fan-out talk. The primary source behind the News Feed walkthrough’s hybrid design; hearing the operators say it lands differently.
Infrastructure core (week 4 and the infra deep-dive track)
- Dynamo: Amazon’s Highly Available Key-value Store — if you read exactly one paper, this one. Quorums, consistent hashing, hinted handoff, vector clocks — the week 4 vocabulary, from the source.
- The Log: What every software engineer should know — Jay Kreps. Why the log is the unifying primitive behind queues, replication, and stream processing. Reframes week 6 and quietly explains half of week 7.
- How to do distributed locking — Kleppmann. The fencing-token argument. Read the Redlock rebuttal too and form your own view — having one is a senior signal.
- Raft, visualized — the interactive walkthrough. Fifteen minutes to durable intuition for leader election and log replication; no paper required.
- Jepsen: Consistency Models — the clickable map of linearizable/sequential/causal/eventual and what implies what. The reference you’ll return to when an interviewer says “but is that linearizable?”
Operating systems at scale (weeks 6–8)
- The Tail at Scale — Dean & Barroso. Why p99 is the number that matters and what fan-out does to it. Changes how you talk about latency in every design.
- Timeouts, retries, and backoff with jitter — Marc Brooker, AWS Builders’ Library. The failure-handling mechanics every “what if it’s slow?” follow-up is fishing for.
- Avoiding insurmountable queue backlogs — AWS Builders’ Library. Backpressure and lag as first-class design inputs; pairs directly with the distributed queue walkthrough’s capacity failures.
- Google SRE Book — Chapters on SLOs and Monitoring — the canonical source for SLI/SLO/error-budget thinking. Chapters 4 (Service Level Objectives), 6 (Monitoring Distributed Systems), and 10 (Practical Alerting) are the production-thinking foundation. Read these if you can’t fluently explain error budgets or symptom-based alerting.
Specialized (weeks 7–9)
- Deep Neural Networks for YouTube Recommendations — Covington et al. The two-stage funnel from the team that canonized it; read the architecture sections, skim the ML.
- A Brief Primer on Anycast — Cloudflare. CDN routing from the operator who bet everything on anycast; ten minutes, permanent intuition.
The DDIA question
You do not need to read Designing Data-Intensive Applications cover to cover before interviews. But if you want to deepen weeks 4–7 considerably, the chapters on replication (ch. 5), partitioning (ch. 6), transactions (ch. 7), and stream processing (ch. 11) are the best single resource on those topics. Read them as supplements, not prerequisites. The official page has chapter summaries.
Skip, without guilt: aggregator “system design primers” (secondhand versions of the above), YouTube mock-interview marathons (watching is not practicing), and any new resource discovered in week 9 (taper means taper).
What to cut if time is short
Four weeks instead of nine: keep weeks 1, 2, and 4 intact — they’re the spine. Compress weeks 5 and 6 into one (order processing + ad-click, practice only order processing) and drop week 3 to a single chat skim. Drop week 7 to two skims (search, recommendation). Keep both week-8 mocks — cut reading before cutting practice, always. Skip the infrastructure deep-dive track entirely unless your loop is infra-focused. Extended reading shrinks to three items: Dynamo, The Log, and the latency numbers.
Never cut: the attempt-before-reading rule, the two week-8 mocks, the follow-up ladder practice, or the taper. The most common self-sabotage is reading new material the night before the loop.
The north star
By week 9, you should be able to:
- Clarify requirements quickly and identify the hard sub-problem.
- Estimate capacity confidently and let numbers drive decisions.
- Build a coherent architecture within the pacing rubric.
- Defend tradeoffs — what you chose, what you rejected, and why.
- Discuss failures, operations, and production concerns fluently.
- Handle unfamiliar follow-ups without panicking, using the follow-up ladder.
That’s what senior system design interviews measure. The boxes and arrows are only the visible part. The underlying skill is engineering judgment — made audible.
Important
Key takeaway: If every red Challenge yourself question across the nine weeks reads like something you could answer out loud without notes, you’re ready. The checklist two days out should confirm what you already know — not teach you anything new.
After you pass
System design judgment compounds outside interviews too — the same tradeoff vocabulary runs design reviews and promo packets. When the offer lands, the career development resources pick up where this plan stops.