A System Designer guide
A two-week system design interview plan
Fourteen days of lessons, traffic experiments and design explanations, with Interview mode in the second week. Every task links to a real lesson or problem.
Use this as a sequence of focused sessions, not a promise of interview success. If a mechanism still feels like a name on a box, repeat that day before moving on. Keep a notebook of predictions and results so progress means better decisions rather than more finished pages.
How to use each session
Read the linked lessons, try the named problem and write a short explanation afterwards. During the first week, use Practice to investigate failures. During the second week, use Interview mode on Medium and Hard problems before reading hints or reference designs. Its clock guides the session; the exercise is to lead the reasoning and test your claims.
Day 1: Start with one request
Lessons: Your first system · What a request is, and p50 versus p99.
Problem: URL shortener · Practice.
Follow a request from the user to the store and back. Name the work on that path and where the response-time target applies. Finish the introduction, then attempt the shortener without looking at the editorial. Save your first bottleneck prediction.
Day 2: Do the numbers
Lessons: Numbers you can do in your head · Spreading load.
Problem: URL shortener · Practice.
Repeat the shortener. Separate its normal peak from its viral event. Estimate capacity with spare room, then check whether that spare room survives losing capacity. Record the difference between your estimate and the run.
Day 3: Remember repeated answers
Lessons: Remembering answers · Copies near users.
Problem: News site · Practice.
Identify which reads can share an answer and how stale it may be. Predict the effect of a cold cache before running. Keep the original data separate from copies that can be rebuilt.
Day 4: Move work off the reply path
Lessons: Waiting instead of breaking · Exactly once, on purpose.
Problem: Package tracking · Practice.
Trace acceptance and completion separately. Write down the waiting deadline and the duplicate policy. Watch the age of waiting work as well as its count; a queue is only useful if work can finish in time.
Day 5: Keep copies honest
Lessons: Copies are a little behind · Which copy is the truth.
Problem: Restaurant reservations · Practice.
Explain where a newly saved booking is read back and what happens if a copy is behind. Write the rule that prevents conflicting reservations, then distinguish it from the traffic capacity you measured.
Day 6: Prepare for pressure
Lessons: Saying "slow down" politely · Timeouts and failing fast · Adding servers, and why it is late.
Problem: Rate limiter for a public API · Practice.
Compare refusing excess work, waiting for it and adding capacity. State the limiter outage policy. A scheduled crowd can arrive before new servers are ready, so predict the first interval separately from later recovery.
Day 7: Review the first week
Lessons: Where the money goes · How to lead a design interview.
Problem: Notification service · Practice.
Do a complete attempt with a written scope, estimates and one failure prediction. Read the debrief only after recording your explanation. Write the requirement, mechanism, alternative and measurement behind one decision.
Day 8: Lead the API discussion
Lessons: Many customers on one system.
Problem: Rate limiter for a public API · Interview.
Ask about per-customer fairness and shared counters before choosing a mechanism. Use the timed flow, then defend an outage policy and test one claim. Keep measured traffic results separate from written reasoning.
Day 9: Defend delayed work
Lessons: Work across services · SLOs and error budgets.
Problem: Notification service · Interview.
Clarify urgency, provider acceptance and expiry. Explain how a lost reply differs from a confirmed failure. Defend the queue policy with observed waiting time and a tested claim about a changed workload.
Day 10: Handle a weak connection
Lessons: Live sockets and presence · Ordering and time.
Problem: One-to-one chat · Interview.
Clarify ordering and the identity of a message across retries. Estimate message traffic separately from open connections. Explain the recovery path after a lost acknowledgement, then compare it with what the run proves.
Day 11: Protect a booking
Lessons: Search is a copy · Copies and quorums.
Problem: Hotel booking · Interview.
Separate search results from authoritative booking state. Explain what happens when a dependency is slow or a replica is behind. Defend which work can use an old copy and which operation must wait or fail.
Day 12: Bound fanout
Lessons: One post, millions of feeds · When one item is popular.
Problem: Social feed · Interview.
Explain how an ordinary account and a celebrity change write amplification. State the promise for your own post. Test a claim about a hot item and defend the point at which you would change the policy.
Day 13: Design for the known rush
Lessons: Surviving a region · Seeing problems early.
Problem: Concert ticket drop · Interview.
Use the scenario’s event peak, not its quiet baseline, for admission planning. Trace a retry through seat holds and payments. Defend a failure experiment and identify the user promise that extra capacity alone cannot protect.
Day 14: Repeat and compare
Lessons: The simplest thing that works · Designs that other teams must live with.
Problem: One-to-one chat · Interview.
Start again from the brief without loading your old design. Compare the quality of your clarification, estimates and tested claims with day ten. Keep one concrete weakness to practise next and one unnecessary part you removed.
What to keep after two weeks
- A scope and a user promise you can state before choosing services.
- Estimates with units, peaks and downstream limits made explicit.
- A failure trace that explains durability, ordering or duplicate handling.
- An experiment with a prediction, result and reason for the next change.
- A trade-off tied to a requirement and a condition that would reverse your choice.
A report is a record of one attempt. Revisit a different problem using the same mechanism, or try a New twist after passing in Practice, to check whether the idea transfers. Keep the traffic score separate from checked learning progress and from your own review of the written explanation.