The System Design Lab

⏱ ~9 min read · 🎧 8 min listen · ✎ 3 quizzes · 🧪 ~90 min lab

This lesson is mostly lab. You've spent four lessons collecting the tools — trade-off thinking (02), reading systems for data flow and failure modes (03), distributed-systems intuition (04), and ADRs (05). Today you use all of them at once, on a realistic scenario, and produce the single most reusable artifact in your evidence trail: a design doc. It's the document promotion committees point at, and it's the exact structure a system design interview compresses into 45 minutes. But first, ten minutes of teaching: the shape of a good one.

The shape of a design doc

A design doc is not a spec and not a diagram dump. It's a decision-making device: it exists so that reviewers can disagree with you efficiently. Richards and Ford's second law of architecture — why is more important than how — is the whole genre in one line.¹ Six sections do the work:

The most common failure isn't a missing section — it's scale numbers as decoration. Weak docs quote the traffic figures and then present a design that would be identical at one-thousandth the load. Strong docs state assumptions and numbers first and let them make decisions: this write rate is why we partition; this read/write ratio is why the cache exists; this data volume is why full-text search gets its own store. If deleting a number from your doc changes nothing downstream, the number wasn't doing anything.²

The same doc, compressed to 45 minutes

Here's the good news for your interview track: a system design interview is not a different skill. It's the same six sections, compressed and spoken aloud. The System Design Primer — the most-starred interview prep resource in existence — teaches exactly this sequence for a 45-minute round:²

And the grading rubric is the same in both rooms. Design reviewers and interviewers are not grading the boxes — dozens of candidates draw roughly the same boxes. They're grading the trade-off narration: did you state assumptions before designing, did the numbers drive the choices, and when you picked X over Y, did you name what Y would have bought you and why you paid the price anyway.¹ A wrong-but-well-reasoned choice scores higher than a right-but-unexplained one.

🧪 Lab: design TicketFlow

Your scenario. TicketFlow is a customer-support ticketing platform your company is building for business customers. Product has committed to the following, and you own the design:

1. Estimate first (15 min). Before any boxes: 2M tickets/day is what in writes/sec, average and peak? With comments and updates, what's the real event rate? At a few KB per ticket, what's a year of data? What does 99.9% allow you per month? Write these at the top of the doc — they are your design's inputs, not its garnish.
2. Write the doc (90 min, two pages max). Use the six sections in order. The data-flow section must let a reader trace one ticket from creation to searchable, SLA-timed, and webhook-delivered.
3. Weigh two alternatives fairly. Candidates: search inside the primary database vs. a dedicated search index; SLA timers by polling vs. a delay queue; webhooks fired inline vs. through a queue with retries. Pick the two most load-bearing for your design.
4. Write one ADR (Lesson 05) for the hardest decision you made — full context, options, decision, consequences. Attach it to the doc.
5. Add a failure-mode table (Lesson 03). At least four rows: what fails, blast radius (which customers, which features), how the system degrades, how you'd know. "Search is down but tickets still flow" is a design property — show it.

Grade yourself against the rubric before you bring it in: (1) the scale numbers drive the design — delete one and something downstream stops making sense; (2) at least two alternatives are weighed fairly, in their strongest form, not as strawmen; (3) every failure mode names a specific blast radius, not "the system degrades"; (4) a smart non-expert stakeholder could read the doc and follow the argument.

Feedback loop, two flavors. First: bring the doc to chat and I'll run a Principal-level design review on it — numbers-drive-design, fairness of the alternatives, and blast-radius specificity are exactly what I'll grade. Second, when you're ready: say the word and I'll play interviewer for a 45-minute mock using the five-stage structure above, pushing on your deep dive the way a real panel would. Keep the doc and the ADR — they go straight into Lesson 12's promotion packet, and TicketFlow becomes a rehearsed interview story.

You are a seasoned Principal Engineer running a design review on my work: a two-page design doc (with an embedded ADR) for TicketFlow, a ticketing platform handling 2M tickets/day at 99.9% availability. Grade it against this rubric:

- Numbers drive the design: delete a scale number and something downstream stops making sense — no decoration.
- At least two alternatives weighed fairly, in their strongest form, not as strawmen.
- Every failure mode names a specific blast radius — which customers, which features, what keeps working — never just "the system degrades."
- A smart non-expert stakeholder could follow the argument end to end.

Grade each criterion Strong / Adequate / Missing with one sentence of evidence. Be skeptical — challenge the weakest claim first. Then ask me 2–3 follow-up questions a design-review panel or interviewer would ask. Finish with the single highest-leverage improvement. If I ask, you may instead run this doc as a 45-minute system design mock interview, stage by stage.

My TicketFlow design doc follows below.

Check yourself — grade like a reviewer

Three scenarios. Apply the model — assumptions first, numbers drive, narrate the trade-offs. Wrong picks stay live.