Question Breakdowns Overview
A question breakdown is a worked example of the delivery framework, not a diagram to memorize.
What, why, when and how
What is it?
A question breakdown derives an example design from scoped product behavior and stated assumptions.
Why is it needed?
Worked cases help practice mechanisms and failures, but memorizing a diagram hides changed requirements.
When should I use it?
Choose a case after identifying the particular reasoning gap you want to repair.
When should I choose something else?
Do not equate a named product with a complete specification or count the four transfer exercises as four fully routed canonical cases.
How do I use it?
Save your requirements, estimate, APIs, state, baseline and failure trace before opening hints; compare decisions, then change one constraint.
Can you show a concrete example?
Nearby restaurant retrieval transfers to driver discovery, but driver dispatch adds an exclusive assignment transition that restaurant browsing does not need.
Read the diagram
35 named walkthroughs = 32 original + 3 extended; Four extra transfer exercises remain separate; Save your attempt, compare decisions, change one requirement
Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.
Outcome: select a problem from the skill you need to practice, produce your own design first, and transfer the mechanism without importing irrelevant product behavior.
This library contains 35 named problem walkthroughs: the original 32 cases plus Video Streaming, Live Video Streaming and Splitwise. It also includes four separate transfer exercises below. The counts describe curriculum coverage, not claims about interview frequency or company difficulty. A worked problem is a model of reasoning under its stated assumptions, not a replica of a private production system.
What to produce before opening a solution
Write two or three included user actions, exclusions, success criteria and the rule that must survive failure. Add a workload estimate only when it changes a design choice. Define the important entities, one write contract and one read contract. Draw a complete baseline, then test a replay, race or timeout before adding scale.
| Evidence | Weak answer | Useful answer |
|---|---|---|
| Requirement | “Design a large messaging app” | State devices, ordering scope and the meaning of send acceptance |
| State | “Use a database” | Name the authoritative message and operation identity |
| Capacity | “Millions of users” | Calculate the relevant peak rate, fanout or bandwidth with units |
| Mechanism | “Use a queue for reliability” | Explain what persists before acknowledgement and what redelivery repeats |
| Failure | “Retry everything” | Preserve identity and reconcile an outcome that may already have succeeded |
| Alternative | “This stack is best” | Compare a simpler option against the same success and recovery requirements |
Save the attempt before reading hints. Practice routes retain their existing solution reveals. The reference walkthrough can be used afterward to compare decisions. Reading a familiar diagram is not evidence that you can construct or repair it.
Choose a family from a demonstrated gap
| Skill to repair | Candidate cases | What transfers | What must be clarified again |
|---|---|---|---|
| Exclusive ownership | Ticketmaster, Online Auction, Flash Sale | Atomic winner transition and retry identity | Hold expiry, bid deadline, checkout/payment policy |
| Durable compute | LeetCode, Job Scheduler, Notification System | Durable intent, current attempt and bounded work | Untrusted code, calendars or provider effects |
| Location | Yelp, Uber, Local Delivery Service, Strava | Candidate narrowing and staleness policy | Exact radius, ETA, driver assignment or offline samples |
| Feeds and search | FB News Feed, Instagram, FB Post Search | Projection lag, pagination and visibility | Ranking, fanout, text matching and deletion contract |
| Concurrent state | Google Docs, Online Chess, Splitwise | Versioned operation and authoritative rules | Merge semantics, legal turns or money conservation |
| Media | YouTube, Video Streaming, Live Video Streaming | Verified publication and controlled delivery | On-demand buffer, live-edge delay, DVR and rights |
| Stream aggregates | Ad Click Aggregator, YouTube Top K, Metrics Monitoring | Identity, event time and correction | Billable qualification, ranking windows or telemetry coverage |
| External uncertainty | Payment System, Robinhood, Notification System | Stable effect identity and reconciliation | Charge/fill/submission state and supported external interface |
Run a transfer experiment with one changed requirement
Start with a restaurant search. A spatial index returns nearby candidates; an exact predicate and current eligibility decide which places appear. Change the prompt to driver dispatch. Spatial selection remains useful, but the design now needs an authoritative transition that assigns an available driver to one trip. Returning the nearest driver's ID from a cache does not reserve that driver.
Read the diagram
Restaurant search: spatial candidates + exact filters; Driver discovery: candidates may be stale; Dispatch: atomically assign one available driver; Lost reply: same assignment identity retrieves outcome
Next compare a ticket hold with an auction close. Both involve competition and time, but an auction must define which bid was admitted before the close and how the winner is finalized. A ticket policy must define whether an unexpired hold may convert into a purchase. Do not rename a hold table into a bid table and declare the contracts equivalent.
Browse all 35 walkthroughs
The following links use the reference-library routes for existing activity identities. The first thirty-two are the original case set; the last three are extended walkthroughs. The index does not mark any semantic review task complete merely because a link exists.
| Walkthrough | First question to establish |
|---|---|
| Bitly | Collision and uniqueness protocol |
| Dropbox | Chunk/file generations |
| Local Delivery Service | Store and courier selection |
| Ticketmaster | Overlapping seats and holds |
| FB News Feed | Hybrid fanout threshold |
| Tinder | Geographic discovery and exposure history |
| LeetCode | Untrusted execution boundary |
| Conversation ordering scope | |
| Rate Limiter | Fixed-window boundary burst versus token-bucket policy |
| YouTube | Verified media publication |
| FB Live Comments | Connection fanout and slow consumers |
| YouTube Top K | Window definition and event time |
| Uber | Location staleness versus dispatch authority |
| Web Crawler | URL normalization and seen-state boundaries |
| Ad Click Aggregator | Transport duplicates versus billable qualification |
| FB Post Search | Text/phrase matching versus ranking |
| Yelp | Spatial candidates plus exact radius |
| Publish media generations | |
| Strava | Offline sample sequence and chunk identity |
| Distributed Cache | Routing ownership and migration |
| Online Auction | Bid admission and close-time ordering |
| Job Scheduler | Calendar/time-zone semantics |
| News Aggregator | Source identity and canonicalization |
| Price Tracking Service | Observation ordering and product variants |
| Notification System | Preference ordering |
| Robinhood | Order intent versus market fill |
| Google Docs | Chosen operation model and convergence contract |
| Payment System | Money representation and double-entry invariant |
| Metrics Monitoring | Series cardinality |
| Online Chess | Server-authoritative legal turns |
| ChatGPT | Turn and stream attempt identities |
| Flash Sale | Inventory authority |
| Video Streaming | Separate control and media paths |
| Live Video Streaming | Glass-to-glass latency budget |
| Splitwise | Per-currency conservation |
Use the extra transfer exercises separately
Food Review App, Game Leaderboard, Donations Website and a GitHub Actions-style runner are four additional original prompts. They do not increase the named walkthrough count from 35 to 39. Attempt their deliverables independently, then read the explained solution. Their names describe the exercise domain, not a claim that those products use our proposed architecture.
The assumptions in the prompts below are inputs for arithmetic and design. Challenge an assumption if it is unreasonable, record the replacement and explain which choice changes. A different valid design must still enforce the invariant and acknowledge the same external uncertainties.
Additional practice: Food Review App
Design an original review product. Users search restaurants, write one review per restaurant, edit it and view a rating. Assume 20,000 searches/s at peak, 200 review writes/s, a 200 ms search target and current author authorization. Clarify whether review deletion and moderation change the visible count.
Deliver a restaurant/review schema, a unique user/restaurant ownership rule, create/edit API contracts, a spatial/text candidate path and one replay-safe aggregate update. Test two concurrent creates, an edited rating, a hidden review and a stale search projection. Judge your answer by whether ownership is enforceable, the aggregate is mathematically valid and visibility is current; naming a search engine earns no credit alone.
Read the diagram
Ratings 2 and 4: sum 6, count 2; Edit 2 to 5: add 3 once; sum 9, count 2; Mean = 9 / 2 = 4.5; replay adds zero
Show answer and explanation
Answer: Use a canonical review identity and an atomic unique pair. Versioned edits adjust sum by new minus old and keep count fixed; deletes/moderation have a declared visible-count policy. Search is a derived candidate view, with distance/filter and current visibility applied before response. A 2-to-5 edit adds three to the sum exactly once. Keep counts as well as sums so distributed rating merges are weighted. Rebuild the projection from authoritative review revisions and tombstones.
Additional practice: Game Leaderboard
Design a season leaderboard with top 100, a player's rank and region filters. Assume one million players, 10,000 result events/s at peak and display freshness within five seconds. A match result may be delivered twice or corrected later. Decide how ties, multiple seasons and resets work before choosing storage.
Deliver result identities, a score-contribution model, ranking API/cursors and a correction/rebuild path. Test a duplicate match, a result arriving after a season closes, a changed result and one popular top-100 page. A valid design explains once-only contribution, deterministic ordering, bounded queries and freshness.
Read the diagram
Match M7 revision 1 contributes 20; Revision 2 contributes 30: replace prior 20; Net correction +10; replay of revision 2 adds zero
Show answer and explanation
Answer: Authoritative match/result revisions own the score facts. A projector applies each applicable contribution once or recomputes a versioned absolute score. A Redis sorted set can serve bounded ranks under the chosen score/tie scheme; cache common pages with a generation. A correction removes/replaces the previous contribution rather than blindly adding a second result. Closed-season policy and replay watermarks prevent an old event from silently entering a new season. A rank cache is rebuildable, not the only record of competition results.
Additional practice: Donations Website
Design a donation product with campaign pages, payment acceptance and donor receipts. Assume a campaign burst of 2,000 payment intents/s, provider limits below that burst and a p95 intent-acceptance target of 300 ms. The provider can time out after accepting a charge, and callbacks can duplicate or reorder. Clarify fees, currencies, anonymous donors and refund policy.
Deliver integer-amount/currency contracts, tenant/campaign authorization, intent/provider identities, an honest pending status, reconciliation and receipt publication. Test a lost response, a duplicated callback, a late success after a user abandons checkout and two refunds exceeding the donation. Evaluate correctness before throughput.
Read the diagram
Donation D7: 2500 minor units in one currency; Refund R1 claims 1500 under an atomic balance rule; Only 1000 remains: R2 cannot also claim 1500
Show answer and explanation
Answer: Durably create the donation intent and provider operation identity before work is admitted. A timeout remains unknown until resolved using that identity; never create a fresh charge merely to retry. Apply verified callback facts once to a ledger under a valid state/operation model. Reserve refundable amount before provider calls. Publish receipts from committed facts with their own stable identity. Campaign totals are a repairable projection with declared freshness; the provider quota applies across every worker pool.
Additional practice: GitHub Actions-style job runner
Design an original repository-triggered CI runner. A workflow has dependencies, artifacts and per-tenant quotas; jobs execute untrusted code. Assume 5,000 submitted jobs/minute at peak, mixed runtimes of seconds to tens of minutes and a bounded queue-wait target for small jobs. Clarify retry, cancellation, secret access and artifact retention.
Deliver workflow/job/attempt identities, a persisted dependency DAG, bounded admission, isolated runners, lease epochs and immutable artifact publication. Test a lost completion response, a stale runner, a dependency failure, cancellation around artifact upload and an abusive tenant. Evaluate sandbox boundaries, result fencing and fairness separately.
Read the diagram
Job J7 runner A holds attempt epoch 9; A loses lease; runner B holds epoch 10; Publish destination rejects late epoch 9 artifacts
Show answer and explanation
Answer: A durable workflow owns dependency states, while job attempts acquire fenced leases and resume applicable checkpoints. A result compares the current attempt epoch and publishes verified immutable artifacts under the same generation. Secrets are narrowly scoped and absent from untrusted logs/outputs; network/process/resource limits complement appropriate isolation. Queue redelivery is safe through stable job/effect identities, not a promise that arbitrary code executes once. A failed dependency follows a declared skip/retry/cleanup policy, and cancellation cannot undo already completed external effects. Per-tenant queues/shares and global budgets bound noisy-neighbor pressure.
Evaluate improvement instead of diagram similarity
Question: A candidate adapts Yelp to Uber by adding driver icons to the same proximity diagram. What is still missing?
Show answer and explanation
Answer: The assignment contract and its authority: a driver cannot be assigned to two active trips under the agreed rule, location may be stale, and an assignment response can be lost after commit. Add a stable trip/assignment identity, an atomic owner transition and an honest recovery/status path. The candidate-retrieval mechanism alone addresses none of those effects.
Question: What should you record when two worked solutions use different databases?
Show answer and explanation
Answer: Compare access patterns, transaction boundaries, consistency/freshness, recovery and operational cost on the same declared workload. Several products may fit. Record the requirement that makes an option win or fail rather than treating a component mismatch as a grading error.
Continue the practice loop
Use How to Prepare to turn one missed claim into a specific error-log entry and delayed retest. Use the Interview Playbook to rehearse a complete timed answer. A saved attempt, corrected mechanism and successful transfer provide stronger study evidence than a list of pages read.