1. Choosing & Scoping the System
Pick one system, not several — a capstone that shallowly covers three systems demonstrates less than one covered deeply. A good choice is large enough to touch most of this course's modules, but familiar enough that you're not learning the domain and the design process at the same time. Weeks 24–26 already walked you through a ride-sharing dispatch system, a video streaming platform and a distributed chat system in full depth — pick something distinct from those for the capstone, so you're demonstrating the framework on unfamiliar ground rather than repeating a worked example:
- A ticket/seat booking system — concert tickets or flight seats, where two people must never be sold the same seat. Touches strong consistency under contention, inventory locking, and graceful handling of high-demand "flash sale" traffic spikes.
- A collaborative document editor — Google Docs-style real-time co-editing. Touches operational transforms/CRDTs, WebSocket fan-out (Week 20), and conflict resolution between concurrent edits.
- A distributed job scheduler — a cron-as-a-service that runs millions of scheduled jobs reliably. Touches consensus and leader election (Week 23), exactly-once execution guarantees, and handling worker failures mid-job.
Whichever you pick, write a one-paragraph scope statement before anything else — exactly the discipline Week 1 built: what the system does, for whom, and what's explicitly out of scope. "Design a ticket booking system: users search for events and purchase seats, with a hard guarantee that no seat is ever sold twice, even under a flash-sale traffic spike; event creation and payment processing details are out of scope" tells a reader immediately what they're about to evaluate. The worked example running through the rest of this week uses the booking system, to show the framework applied somewhere Weeks 24–26 didn't already cover.
2. Requirements & Estimation
Apply Week 1's framework in full, on paper, before sketching a single box:
Functional:
- A user can browse events and see live seat availability
- A user can select and purchase one or more seats for an event
- The system must never sell the same seat twice
Non-functional:
- Scale: 50M registered users; a popular on-sale event can see
1M+ users trying to buy within the first minute ("flash sale")
- Latency: seat-map view must load in under 300ms; a purchase
attempt must resolve (success or "seat taken") within 2 seconds
- Consistency: strong consistency on seat inventory is
non-negotiable -- unlike most of this course's read-heavy
examples, correctness here matters more than raw throughput
- Availability: the system must degrade gracefully under a
flash-sale spike (e.g. a queue/waiting room) rather than fail
Estimation:
Normal browsing: ~5M DAU browsing casually
-> a few thousand reads/second, unremarkable
Flash-sale spike: 1,000,000 users attempting to buy the same
20,000 seats within 60 seconds
= ~16,700 purchase attempts/second, almost
entirely contending for the SAME small set
of rows -- not evenly distributed load
That last line is the number that should reshape the whole design: this isn't a scale problem in the usual sense (16,700 requests/second is modest by this course's standards) — it's a contention problem, thousands of writers racing for the same few thousand rows at the same instant. A design that treats this as "just add more database replicas" hasn't understood its own system yet; replicas solve read scaling, not write contention on the same rows, which is what Section 3's deep dive actually has to solve.
3. High-Level Design & Deep Dives
Sketch the minimal architecture per Week 1's diagramming discipline, then pick two or three components to go deep on — the ones your own estimation numbers just flagged as the hard parts:
[User] --browse--> [API Gateway] --> [Catalog Service] --> [Read Replica]
(Week 4-5)
[User] --buy seat--> [API Gateway] --> [Virtual Waiting Room] (Week 11's
rate limiter, repurposed as a
flash-sale admission queue)
|
[Booking Service] --> [Seat Inventory]
(single source
of truth per
event, Weeks
9-10 strong
consistency)
|
[Payment/Confirmation] (async, Week 8's
queue -- seat is provisionally locked
before payment, released if it fails)
Deep dive candidates fall directly out of Section 2's contention number, not out of raw scale: the seat-locking mechanism (how do you guarantee exactly one buyer per seat under 16,700 contending attempts/second — an atomic compare-and-swap in the inventory store, or a short-lived pessimistic lock per seat, using the strong-consistency vocabulary from Weeks 9–10), the virtual waiting room (reusing Week 11's rate-limiting algorithms not to reject users, but to admit them into the purchase flow at a rate the Booking Service can actually handle without every request racing at once), and the provisional-lock-then-confirm flow (a seat is held for a short window during payment, then either committed or released — Week 8's queue pattern applied to a reservation instead of a notification). Each deep dive should end with an explicit tradeoff, not just a description of how the component works — see Section 4.
4. Tradeoff Analysis & Failure Scenarios
A design without stated tradeoffs reads as if you don't know what you gave up — every real design decision costs something, and naming that cost is what separates a strong answer from a list of technologies:
- Strong consistency on seat inventory costs throughput and adds latency under contention (every purchase attempt for a hot seat serializes behind the same lock) — worth it here because a double-sold seat is a broken product experience and a real-world liability, unlike a stale view count elsewhere in this course.
- The virtual waiting room costs perceived fairness and adds a step most users resent (nobody likes a queue) — worth it in exchange for the Booking Service never receiving more concurrent requests than it can correctly serialize, which is what actually prevents the system from falling over during a flash sale.
- Provisional locking during payment costs a seat sitting "held but unconfirmed" for a short window, briefly reducing available inventory below the true number, in exchange for never charging a user for a seat that got sold to someone else mid-payment.
Then walk through at least one failure scenario end to end, the way an interviewer's follow-up question would: "what happens if the Payment Service goes down for 30 seconds during an on-sale?" A strong answer names the concrete user-facing impact (users see a "payment pending, please wait" state rather than an error; the seat stays provisionally locked to them, not released back into inventory), and the recovery path (a background job releases any lock whose payment never confirmed within its timeout window, and the affected users are notified their hold expired — no seat is silently lost, and no user is silently charged without a confirmed seat).
The strongest design interview answers use "it depends" as an opening, not an ending: "it depends — if contention were rare, I'd favor a lightweight optimistic check; here, given thousands of buyers racing for the same seat, I'd favor..." A tradeoff stated without the "and here's what determined my choice for THIS system" half sounds like uncertainty rather than judgment.
5. Writing the Design Doc
Compile Sections 1–4 into a single document a reviewer could read without you in the room — the actual artifact this capstone produces:
- Scope — the one-paragraph statement from Section 1.
- Requirements & estimation — the functional/non-functional list and the math from Section 2, shown, not just stated.
- Architecture diagram — the sketch from Section 3, legible on its own.
- Deep dives — each component you went deep on, with its tradeoff explicitly stated.
- Failure scenarios — at least one, walked through end to end, from Section 4.
- What you'd do differently — an honest note on what you'd reconsider with more time or a different constraint (e.g. global scale instead of single-region).
Then rehearse presenting it out loud, against a 35–40 minute timer, the length of a real system design interview round. Recording yourself and listening back is uncomfortable and disproportionately useful — it's the fastest way to notice you're spending twelve minutes on the diagram and two minutes on tradeoffs, when a real interview rewards roughly the opposite balance.
6. The Capstone Project
Design, document and rehearse one large system end to end
Take one system from Section 1's list (or one of your own choosing of comparable scope) fully through Sections 1–5: scoped, estimated, designed, analyzed and written up.
Requirements:
- Write the scope statement and full functional/non-functional requirements list before doing any estimation math (Section 1).
- Complete the back-of-envelope estimation — average and peak throughput for every distinct traffic pattern in the system (not just one aggregate number), plus a storage estimate (Section 2).
- Produce a high-level architecture diagram and go deep on at least two components, each ending in an explicit tradeoff (Section 3).
- Walk through at least one realistic failure scenario end to end, naming the user-facing impact and the recovery path (Section 4).
- Write the complete design doc covering all six sections from Section 5.
- Rehearse presenting the design out loud against a 35-40 minute timer at least twice, ideally recorded.
Presenting to an empty room and presenting to someone who can ask a follow-up question you didn't anticipate are very different exercises — the second is what actually simulates an interview. If you can't find a partner, write down three follow-up questions you'd expect an interviewer to ask, and answer them cold before checking your design doc.
7. Final Checklist
Before calling the capstone — and the course — done, confirm each of these honestly:
✓
Were the requirements and estimation written down before the architecture diagram was drawn?
Were the requirements and estimation written down before the architecture diagram was drawn?
A diagram drawn first and justified afterward tends to describe a generic, memorized architecture rather than one derived from this system's specific numbers. If the estimation step genuinely happened first — the way Section 2's contention number (16,700 attempts/second racing for the same rows) reshaped the booking design — the diagram should visibly reflect it, with the contended path getting the most deliberate design attention, not just the highest-throughput one.
✓
Does every deep-dive component end with an explicit tradeoff, not just a description of how it works?
Does every deep-dive component end with an explicit tradeoff, not just a description of how it works?
Explaining how an atomic compare-and-swap on inventory works is a knowledge check; explaining what you gave up by choosing a pessimistic per-seat lock over an optimistic retry-on-conflict approach is a design decision — the second is what an interview loop is actually scoring. A deep dive that only describes mechanics, with no stated cost, hasn't demonstrated judgment yet.
✓
Was at least one failure scenario walked through with a concrete user-facing impact and recovery path, not just "it would handle failures gracefully"?
Was at least one failure scenario walked through with a concrete user-facing impact and recovery path, not just "it would handle failures gracefully"?
"It would handle failures gracefully" is a claim with no evidence behind it. Naming the specific component that fails, what a user actually experiences during that failure, and the specific mechanism that recovers it — the way Section 4's Payment Service outage was traced through to "users see a pending state, held seats expire safely via a background job" — is what proves the design was actually reasoned through rather than asserted.
✓
Was the design presented out loud against a timer, not just written down?
Was the design presented out loud against a timer, not just written down?
A design interview scores real-time communication and time management alongside the design itself — spending twelve minutes on a diagram and two on tradeoffs is a failure mode that's invisible on paper but obvious the moment you rehearse against a clock. If this step was skipped, the capstone has produced a design doc but not yet practiced the actual skill the course exists to build.