Deriving a Design from Requirements — Don't Recite an Architecture, Derive One
Deriving a Design from Requirements — Don't Recite an Architecture, Derive One
Open the next "Design X" page and watch what your brain does. If it reaches for the picture — the load balancer, the app tier, the cache, the sharded DB, the queue — you have already lost the interview, because that is exactly the reflex an IC6 loop is built to expose. Reproducing a reference diagram is a memory skill. Deriving one from the requirements is a reasoning skill, and reasoning is the only thing that survives a follow-up. This page is the thinking arc that should run before every "Design X" page in this section. Read it once, then let it sit on top of every design you attempt.
The mechanism to internalise is a chain of forced moves: requirements pin down constraints → constraints get quantified by back-of-the-envelope (BOTE) numbers → the numbers eliminate whole classes of architecture → what survives elimination is your design. Every box on the whiteboard should be traceable back to a number or a stated requirement. If you can't trace it, you recited it.
The scaffold: RESHADED, but derived at every step
The order below is the standard interview spine. What makes it a derivation and not a recital is that each step consumes the output of the one before it — nothing appears from memory. Say each step out loud; the interviewer is scoring the arrows between steps, not the boxes.
| # | Step | What you produce | What it forces in the next step |
|---|---|---|---|
| 1 | Requirements | Functional (the verbs: shorten, redirect, post, read) and non-functional: consistency need, latency SLO (p99), read/write ratio, availability target, scale horizon. | Pins the ONE constraint that dominates. ("Redirects must be <50ms p99 and never 404 a live link" is a different system than "analytics can lag 10 min".) |
| 2 | Estimation (BOTE) | Users → peak/avg QPS → storage/yr → bandwidth. Do this before drawing anything. | The numbers decide the architecture. 150k write QPS on one primary is physically impossible → you must partition. That's a forced move, not a preference. |
| 3 | System interface (API) | The handful of endpoints that satisfy the functional reqs: POST /urls, GET /{code}. | Names the read path and write path separately — which the QPS split says to scale independently. |
| 4 | Data model | Entities, access patterns, the key you look up by. | Access pattern + scale → storage engine and partition key. (Point-lookup by short code at 100:1 read/write → a KV store keyed on code, not a relational scan.) |
| 5 | High-level design | The boxes — but each one justified by a number or requirement from steps 1–4. | A skeleton you can now attack. |
| 6 | Detailed design | Zoom into the one or two components the dominant constraint stresses (the hot path, the partition scheme, the cache invalidation). | Surfaces the real trade-off you'll defend. |
| 7 | Evaluate | Bottlenecks, single points of failure, failure modes, cost. Name each trade-off you took. | Shows you know what you gave up. |
| 8 | Distinguishing | The deeper move — the thing a mid-level candidate wouldn't reach: a second-order failure, a cheaper alternative you rejected and why. | This is the IC5→IC6 signal. |
Notice steps 5–8 (the diagram) are the back half. The recite-instinct starts at step 5 and skips 1–4 entirely, which is why it produces a plausible drawing that answers no actual question.
Let the numbers drive — a BOTE that forces the architecture
The single most convincing move in a design interview is to make a number eliminate an option in front of the interviewer, so the surviving option looks inevitable rather than chosen. The pattern: estimate → hit a ceiling → the ceiling rules something out.
Prompt: design a write-heavy event/metrics ingest.
Requirements pass: ~15M daily active clients, but NOT all online at once. At peak,
say ~1% are live concurrently -> ~150k concurrent clients, each
emitting ~1 event/sec. (Write the concurrency assumption down:
"15M x 1/s" = 15M QPS is the classic DAU-vs-concurrent unit error.)
Estimation pass:
peak write QPS = 150,000 concurrent clients x 1 ev/s x (burst factor ~2)
~= 300k writes/sec at peak; ~150k QPS sustained.
A single primary tops out around ~10k-50k write QPS (fsync + WAL + one CPU's worth
of commit throughput), no matter the tuning.
Forced move: 150k sustained >> ~30k ceiling of one primary
=> you CANNOT single-primary. You must PARTITION the write path.
=> now a real question appears: partition by what key? (client_id?
time? hash?) -- and THAT is the trade-off you actually discuss.You did not "decide to shard because big systems shard." A number crossed a physical ceiling and removed the single-node option; sharding is what was left standing. The interviewer sees the reasoning, not a memorised conclusion — and the follow-up ("why partition by X?") lands on ground you built, so you can defend it. Contrast the recite version: "it's high scale, so we'll shard the database" — true by luck, indefensible under "why, and at what QPS would you not have?"
Side by side: the same prompt, recited vs derived
Same question — "Design a URL shortener." Read both openings and feel the difference in what each one earns.
| The recited answer (weaker instinct) | The derived answer (the signal) |
|---|---|
| "A URL shortener maps a long URL to a short code. We'll have a load balancer, an app server, a cache like Redis, and a database. The app generates a short code, stores the mapping, and on read we look it up, checking the cache first. We can shard the database and add a CDN." | "First, what dominates? Redirects vastly outnumber creates — this is read-heavy, ~100:1. And a redirect is on a user's critical path, so the constraint is read latency and availability, not write throughput." |
| Every piece is generic. Nothing ties the cache, the shard, or the CDN to this problem — the same paragraph would "design" a pastebin, a feed, or a KV store. It answers no specific constraint. | "BOTE: say 100M new links/day → ~1.2k write QPS, but ~120k read QPS at peak. Storage: 100M/day x ~500B x 5yr ≈ ~90TB — fits a partitioned KV store easily; no exotic engine needed." |
| First follow-up — "why a cache? what hit rate? why shard at 1k write QPS?" — and it unravels, because the boxes were never derived from anything. | "So: KV store keyed on short code (point lookups, no joins); code = base62 of a counter/hash for O(1) generation and no collision scan; heavy read caching because 100:1 makes cache hit-rate the p99 lever; writes are trivial (1.2k QPS — a single primary is fine, no sharding needed for throughput, only for the 90TB)." |
| Outcome: a plausible picture that screams "I've seen the diagram." | Outcome: every box traces to a number. Sharding is justified by storage, not throughput — and being able to say "I would not shard for write load here" is the whole game. |
The recited version isn't wrong — it's undefended. It arrives at boxes without the reasoning that makes them the right boxes, and the interview is a machine for extracting exactly that missing reasoning.
How to study the problem pages (the antidote to bimodal prep)
This section is built in two layers on purpose. Every base "Designing X" page has a deeper "Traced" companion (e.g. Designing Twitter Timeline — Fan-out Traced, Designing Ticketmaster — Seat Reservation Traced, Designing YouTube — Video Streaming, Traced). Use them in this order, or you will train the wrong reflex:
- Read only the prompt and requirements. Close the page.
- Derive it yourself through the scaffold above — out loud, on paper: clarify, BOTE, interface, data model, then the boxes. Commit to an architecture and the numbers behind it.
- Now open the base page and check your derivation against it. Where you diverged, ask why — did you miss a requirement or a number?
- Then read the "Traced" companion for the deep mechanism and the follow-ups.
This matters because prep is bimodal: passively reading the finished design installs the recite instinct (you recognise the diagram, feel fluent, and freeze when the interviewer changes one requirement), while deriving first and using the page as an answer key installs the reasoning instinct that transfers to a problem you've never seen. The pages are the check, deliberately downstream of your own derivation — the same role the reference architecture plays inside a single interview.
Pitfalls
- Skipping the BOTE to "save time." The estimate is not overhead — it is the step that turns your architecture from a preference into a forced move. Skip it and every box becomes a taste you have to defend by assertion.
- Estimating, then ignoring the number. Common and fatal: candidates compute 1.2k write QPS and then shard the write path anyway out of habit. If a number doesn't change a decision, you didn't use it — say what it rules in or out.
- Clarifying functional requirements only. "It should shorten and redirect URLs" is the easy half. The design is decided by the non-functional half — consistency, p99 SLO, read/write ratio, availability — so drag those out first.
- Drawing before deriving. The instant a box appears on the board with no number or requirement behind it, you've reverted to recite mode. Guardrail: for every component, say the number that justifies it.
- Treating the reference architecture as the goal. It's a checklist at the end ("did I forget a standard piece for this class of problem?"), not the template you fill in at the start.
When reciting is actually fine (and the trade-off)
Derivation costs time — the scarcest resource in a 45-minute loop. So calibrate: for a well-known building block (a rate limiter's token bucket, a leader-election, a write-ahead log) you should name the standard mechanism fast and move on — deriving a WAL from scratch wastes the clock. Reciting is the right tool for components with a settled answer. Derivation is the right tool for the system-level shape: how the components compose, what you partition, where consistency lives, what you cache — because that shape is what changes with the requirements, and it's the only part the interviewer can drill. The failure mode this page targets is applying the recite reflex at the system level, where there is no settled answer, only a derivation. Rule of thumb: recite the parts, derive the whole.
Takeaways
- Every box must trace to a number or a stated requirement. If you can't trace it, you recited it — and the follow-up will find it.
- BOTE first, boxes second. Let a number cross a physical ceiling and eliminate an option in front of the interviewer; the surviving option then looks inevitable instead of chosen.
- Clarify the non-functional half. Consistency, p99 SLO, read/write ratio, availability and scale horizon decide the design — the functional verbs rarely do.
- Recite the parts, derive the whole; the reference architecture is the final check, not the opening move. Study every "Designing X" page by deriving first and reading it as the answer key — that installs the reasoning instinct, not the fragile recite one.
🪜 Drill ladder: Deriving a Design from Requirements
- Clarify before you compute. Given the prompt "design a chat app", write the three requirement questions whose answers change the architecture (e.g. group size cap? message history retention? delivery guarantee?) — and for each, state which component the answer creates or deletes.
- Catch the unit error. A candidate says "15M DAU, so we need to handle 15M concurrent connections." Redo the estimate correctly (15M DAU × ~1% concurrent ≈ 150k, ×2 burst ≈ 300k peak) and explain in one sentence why DAU and concurrency are different units.
- Find the dominating constraint. For a URL shortener at 100M new links/day, compute write QPS (~1.2k), peak read QPS (~120k), and 5-year storage (~90TB), then answer: which of the three numbers actually forces a partitioning decision, and why do the other two not?
- Derive the forced move. Take one requirement flip — "reads must reflect writes immediately" vs "a few seconds of staleness is fine" — and trace how it changes the caching and replication choices; state the ceiling that each option hits first.
- Full derivation under the clock. Pick any solution page in this track you have NOT read, spend 10 minutes deriving requirements → BOTE → ceiling → forced moves, then open the page as the answer key and log every step where you recited a component the numbers didn't force.
🤖 Don't fully get this? Learn it with Claude
Stuck on Deriving a Design from Requirements — Don't Recite an Architecture, Derive One? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Deriving a Design from Requirements — Don't Recite an Architecture, Derive One** (System Design) and want to truly understand it. Explain Deriving a Design from Requirements — Don't Recite an Architecture, Derive One from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Deriving a Design from Requirements — Don't Recite an Architecture, Derive One** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Deriving a Design from Requirements — Don't Recite an Architecture, Derive One** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Deriving a Design from Requirements — Don't Recite an Architecture, Derive One** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.