Lesson 06 · Architecture & System Design
Module 2's capstone: everything from trade-offs to ADRs, compressed into one two-page design doc — and one 45-minute interview.
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.
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.1 Six sections do the work:
| Section | What it must contain |
|---|---|
| Problem & requirements | What we're building and for whom — with scale numbers: users, requests/sec, data volume, growth |
| Constraints & assumptions | What's fixed (team, deadline, tech estate, budget) and what you're assuming — stated so they can be challenged |
| Proposed design | Components and the data flow through them (Lesson 03) — a reader can trace one request end to end |
| Alternatives | At least two roads not taken, each weighed fairly — what you'd gain, what it costs, why it lost (Lesson 02) |
| Failure modes | What breaks, what the blast radius is, and how the design degrades (Lessons 03–04) |
| Rollout plan | How it ships incrementally, what you measure, and how you'd back out |
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.2
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:2
| Interview stage | ≈ Time | Design-doc equivalent |
|---|---|---|
| Requirements & scope | 5–10 min | Problem & requirements — ask, don't assume; say your assumptions out loud |
| Estimation | ~5 min | The scale numbers — back-of-envelope QPS, storage, bandwidth |
| High-level design | 10–15 min | Proposed design — boxes plus the data flow between them |
| Deep dive | 10–15 min | Alternatives + failure modes — the interviewer picks the hard part; you narrate trade-offs |
| Wrap-up | ~5 min | Rollout, bottlenecks, what you'd do with more time |
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.1 A wrong-but-well-reasoned choice scores higher than a right-but-unexplained one.
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:
| Requirement | The commitment |
|---|---|
| Customers | 5,000 business customers (each with their own agents and end users) |
| Ticket volume | 2,000,000 new tickets per day, plus comments and status updates on top |
| Full-text search | Agents search across all their tickets — subjects, bodies, comments |
| SLA timers | Per-customer response-time SLAs; a breach must trigger escalation reliably |
| Webhooks | Ticket events pushed to customers' own systems — flaky endpoints included |
| Availability | 99.9% — you get roughly 43 minutes of downtime per month, total |
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.
Three scenarios. Apply the model — assumptions first, numbers drive, narrate the trade-offs. Wrong picks stay live.
Scenario A
In a system design interview, a candidate hears "design a ticketing system" and immediately starts drawing an elegant microservices diagram — gateway, services, queues, caches. The boxes are all reasonable. Why is the interviewer already marking them down?
Scenario B
A design doc opens with "we expect 2M tickets/day" — then proposes a single relational database with no partitioning, an inline search query using SQL LIKE, and webhooks fired synchronously from the request path. As the reviewer, what's your core objection?
Scenario C
Two failure-mode tables for the same design. Doc 1: "If the search cluster fails, the system degrades." Doc 2: "If the search cluster fails, agents at all 5,000 customers lose search, but ticket create/update, SLA timers, and webhooks keep working; alert fires on index lag." Why does Doc 2 score higher?
Hand-picked follow-ups. None are required — the primary source above comes first.