The design frame
A repeatable thinking frame you carry into every design problem: clarify requirements, estimate scale, sketch a high-level design, deep-dive the hard parts, find the bottleneck, and state every tradeoff out loud. It is scaffolding for reasoning under pressure, not a script.
Put two engineers in front of the same blank whiteboard and “design a news feed.” One freezes, then starts drawing boxes — a server here, a database there — and twenty minutes later has a tangle that does something, for nobody in particular, at no particular scale. The other says: “Let me make sure I understand what we’re building, then I’ll size it, then sketch it, then we’ll dig into the part that’s actually hard.” The second engineer isn’t smarter. They have a frame — a fixed sequence they run every single time — so the blank board never has to be faced from scratch. The frame is the difference between performing and flailing. By the end of this lesson you will have that same sequence — six stages you can walk under pressure, on any system, without blanking.
Why a frame at all
The previous lesson established the reasoning — requirements to bottlenecks to tradeoffs. The frame is that reasoning turned into an ordered, repeatable procedure so you can execute it under pressure, on an unfamiliar problem, without forgetting a step. Experienced designers don’t improvise the order; they have internalized one and walk it deliberately. The value is not the boxes you draw — it’s that you never stall, never optimize before you’ve sized, and never finish without having named what you traded away.
The frame has six stages. They are mostly sequential, but you loop back constantly — a number you estimate in stage 2 can send you back to re-clarify a requirement in stage 1.
The six stages
-
Clarify requirements — functional and non-functional. Functional: what does the system do? (“post a tweet,” “load a timeline,” “search”). Non-functional (NFRs): how well? — latency targets, availability, consistency expectations, durability, read/write ratio. NFRs are where most of the design pressure lives; “the timeline must load in under 200 ms at p99” shapes the architecture far more than “show tweets.” Pin down scope explicitly: what is in, and just as importantly, what is out.
-
Estimate scale (back-of-the-envelope). Turn the requirements into numbers: daily active users, requests per second (peak, not average — peaks are often 2–5× the mean), storage growth per year, bandwidth. You’re not seeking precision; you’re seeking the order of magnitude that tells you whether this fits one box or needs a fleet. 100 RPS and 1,000,000 RPS are different systems, and you can’t pick components until you know which one you’re in.
-
High-level design. Now sketch the major components and the data flow between them — clients, load balancer, app servers, the data stores, the caches, the queues. Keep it coarse. The goal is a diagram that obviously satisfies the functional requirements and that you can point at while reasoning about the non-functional ones.
-
Deep-dive the hard parts. Every design has one or two genuinely difficult pieces; the rest is plumbing. Spend your time there. For a feed it’s fan-out (push vs pull on read). For a rate limiter it’s the counting algorithm and where the counter lives. Going deep on the hard part — and not the easy part — is the single clearest signal of seniority.
-
Identify the bottleneck. At the stated scale, which resource gives out first — a hot database partition, a single coordinator, cache capacity, network egress? Naming it explicitly is what lets you scale the right thing instead of the convenient thing, and it’s directly downstream of your stage-2 numbers.
-
State the tradeoffs out loud. For every significant choice, say what you bought and what you paid: “push fan-out for instant reads, paying expensive writes and a celebrity problem.” A design that lists its tradeoffs is defensible; one that pretends it made only wins is not.
Together these six stages guarantee that you never optimize before you understand, never draw before you size, and never finish without having named what you gave up. Miss stage 2 and your stage 3 diagram is built on fiction; skip stage 6 and the whole exercise collapses into a diagram without a rationale.
The frame is scaffolding, not a script
The danger is treating the six stages as a checklist to recite. A frame is scaffolding for reasoning, not a substitute for it. Reciting “now I will estimate scale” while producing numbers you never use is theater. The stages exist to make sure your thinking covers the right ground in the right order — clarify before you build, size before you choose, go deep where it’s hard, and never hide a tradeoff. Internalize the sequence until you stop noticing it, the way a fluent speaker stops noticing grammar.
▸Common mistake
The most common failure is skipping straight to stage 3 — drawing boxes before clarifying requirements or estimating scale. It feels productive because something concrete appears on the board, but you’ve now committed to an architecture sized for a scale you never established, solving a problem you never scoped. The second most common failure is the inverse: spending so long polishing the high-level diagram that you never deep-dive the one part that was actually hard, leaving the interview (or the real design doc) with a pretty picture and no evidence you can handle the difficulty. Clarify first; go deep on the hard part; both failures come from getting the order wrong.
▸Why this works
Why estimate scale before the high-level design rather than after? Because the scale determines which components are even legal. At 100 RPS with a few GB of data, a single Postgres instance and an app server is not just acceptable — it’s the correct, simplest answer, and reaching for sharding or a message queue would be over-engineering. At 1,000,000 RPS the same diagram is a non-starter and you need partitioning, caching tiers, and asynchronous processing from the first sketch. If you draw the architecture before you know the order of magnitude, you’re guessing — and you’ll either over-build for traffic you don’t have or under-build for traffic you do. The number comes first because it’s the constraint everything else must satisfy.
A candidate is asked to design a chat system and immediately starts drawing servers, databases, and a message queue. What stage did they skip, and why does it matter?
Why does the frame put 'estimate scale' before 'high-level design' rather than after?
The six stages are not a checklist to recite; producing numbers you never use is theater. The frame is best understood as _______ for reasoning — it makes sure your thinking covers the right ground in the right order, but it never replaces the thinking itself.
- 01List the six stages of the design frame in order.
- 02Why must 'estimate scale' come before 'high-level design'?
- 03What does it mean that the frame is 'scaffolding, not a script,' and what's the most common way people misuse it?
The design frame turns the requirements → bottlenecks → tradeoffs reasoning into a fixed, repeatable six-stage sequence you run every time so you never face a blank board from scratch: (1) clarify functional and non-functional requirements — NFRs carry most of the design pressure; (2) estimate scale to the right order of magnitude, because 100 RPS and 1,000,000 RPS are different systems and the number is the constraint everything else must satisfy; (3) sketch a coarse high-level design; (4) deep-dive the hard parts — going deep where it’s genuinely hard, not on the plumbing, is the clearest signal of seniority; (5) identify the bottleneck the scale implies; (6) state every tradeoff out loud, since a design that hides its costs isn’t defensible. The arrows are a default, not a one-way street — you loop back when new numbers reopen scope. Treat the frame as scaffolding for reasoning, not a script to recite; the most common failure is jumping to stage 3 before requirements and scale exist. Unit 09 expands this into the full interview framework with timing and communication tactics. Now when you see someone — or yourself — draw a box before asking a single question about scale, you will know exactly which stage was skipped and why the rest of the diagram cannot be trusted.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.