The Design Framework

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." — commonly attributed to Abraham Lincoln

Back in Part I you learned the shape of the design interview room — the five-phase spine, the rubric, the level expectations. That was the map. This chapter is the vehicle you'll actually drive across it. Every one of the seven case studies that follows — the URL shortener, the news feed, the chat system, the rate limiter, and the rest — is the same method applied to a different prompt. Learn the method once, cold, and each new problem stops being a blank whiteboard and becomes a form you already know how to fill in. That is the difference between candidates who freeze and candidates who look, suspiciously, like they've done this before. They have — they had a framework.

Core Concepts

A design framework is a checklist you internalise so deeply that it frees your mind to think. The paradox of the design interview is that structure is what creates room for creativity: when you never have to wonder "what do I do next?", all your attention goes to the actual problem. The framework below expands Part I's time-boxed spine into seven concrete phases. Each phase has a WHAT (the work you do) and a WHAT TO SAY (the sentence that signals you're doing it — because the interviewer scores what they hear, not what you think).

Here is the whole framework on one canvas, with a minute budget for a standard 45-minute slot:

  PHASE                         MIN   WHAT YOU DO                          WHAT YOU SAY
 ┌──────────────────────────┐ │ 1. CLARIFY REQUIREMENTS  │  ~5   functional + non-functional;         "Let me make sure I'm
 │    & SCOPE               │       pick the core 2-3 features;           solving the right problem…"
 └───────────┬──────────────┘       state what's OUT of scope             ▼
 ┌──────────────────────────┐ │ 2. ESTIMATE              │  ~5   QPS, storage, bandwidth,              "Let me size this before
 │   (back-of-envelope)     │       read/write ratio → drives design      I draw anything…" └───────────┬──────────────┘
             ▼
 ┌──────────────────────────┐ │ 3. API & DATA MODEL      │  ~5   key endpoints; core entities         "Here's the contract and
 │                          │       & schema                              the data it stores…" └───────────┬──────────────┘
             ▼
 ┌──────────────────────────┐ │ 4. HIGH-LEVEL DESIGN     │ ~10   draw the boxes: client→LB→           "Let me sketch the happy
 │   (draw the boxes)       │       services→cache→DB→queue                path end to end…" └───────────┬──────────────┘
             ▼
 ┌──────────────────────────┐ │ 5. DEEP DIVE             │ ~10   interviewer picks 1-2 hard           "The interesting part here
 │   (the hard parts)       │       parts — or YOU propose them           is X — let's go deep…" └───────────┬──────────────┘
             ▼
 ┌──────────────────────────┐ │ 6. BOTTLENECKS & SCALE   │  ~5   where does it break? add             "Where does this fall over
 │                          │       cache/replicas/shards/CDN;            at 10×, and how do I fix it?"
 └───────────┬──────────────┘       kill SPOFs, handle hotspots             ▼
 ┌──────────────────────────┐ │ 7. WRAP UP               │  ~3   trade-offs recap; more-time         "To recap the key trade-offs
 │                          │       list; failure modes                   and what I'd do next…" └──────────────────────────┘

Notice this is Part I's five phases with two seams pulled apart: the API/data-model work gets its own step (3), and "bottlenecks & wrap-up" splits into scaling (6) and an explicit recap (7). The minutes are a contract with yourself, not a stopwatch — but if you find yourself 20 minutes in and still clarifying, you have lost the room.

Phase 1 — Clarify requirements & scope

WHAT: Separate functional requirements (what the system does — "shorten a URL, redirect a short code") from non-functional ones (how it must behave — latency, availability, consistency, durability, security). Then pick the core 2–3 features to design and explicitly name what's out of scope. A prompt like "Design Twitter" hides fifty features; you will design three well, not fifty badly. This is the phase from Part I you skip at your peril — designing before scoping is the number-one failure.

WHAT TO SAY: "Before I design anything, let me confirm the core use cases and the scale. I'll focus on posting and reading the timeline; I'll treat search, ads, and DMs as out of scope for today — shout if you'd rather I prioritise differently." Asking before assuming, and writing the requirements where the interviewer can see them, reads as seniority.

Phase 2 — Estimate

WHAT: Back-of-the-envelope numbers, exactly as in Part I's estimation chapter. Compute QPS (users × actions ÷ 86,400 seconds/day), the read/write ratio (most consumer systems are wildly read-heavy — 100:1 or more), storage per year, and bandwidth. These aren't trivia; they drive every downstream decision. A 100:1 read/write ratio screams "add a cache and read replicas." 50 TB/year of new data screams "you will shard." The numbers tell you which of the later phases actually matter.

WHAT TO SAY: "Assume 100M daily active users, 2 writes and 200 reads each per day. That's ~2,300 writes/sec and ~230,000 reads/sec average — call it 5× that at peak. Read-heavy by a hundred to one, so caching is going to earn its keep."

Phase 3 — Define the API & data model

WHAT: Sketch the key endpoints — the contract clients depend on — and the core entities/schema. You don't need every field; you need the shape. Two or three endpoints and two or three tables (or collections) is plenty. This is where your Volume 3 API instincts and Volume 4 data-modelling pay off, and it forces precision before you hand-wave boxes.

WHAT TO SAY: "The write path is one endpoint, the read path another — here's the shape." A short, honest snippet beats a paragraph:

POST /v1/urls        { "long_url": "https://…" }   -> 201 { "short": "aX9k2" }
GET  /{short}                                        -> 302 Location: https://…

urls ( short_code CHAR(7) PRIMARY KEY,
       long_url   TEXT NOT NULL,
       created_at TIMESTAMP,
       owner_id   BIGINT NULL )

Phase 4 — High-level design

WHAT: Draw the boxes and the request flow — the happy path from client to storage and back. Almost every consumer system is a variation on the same skeleton; start from it and delete what you don't need:

WHAT TO SAY: "Let me draw the happy path first, then we'll break it. Client hits the CDN for static assets, dynamic requests go through the load balancer to a stateless service tier. Reads check the cache, fall back to the DB. Writes go to the DB and drop a message on a queue for anything that can happen asynchronously — fan-out, thumbnails, notifications." Start simple. Resist adding shards and microservices now; you'll add them in Phase 6 when the numbers force you to.

Phase 5 — Deep dive

WHAT: The interviewer will pick one or two genuinely hard parts — or, better, you propose them, which signals you know where the difficulty lives. This is where senior candidates separate themselves. Typical deep-dive targets: the DB choice (SQL vs NoSQL), sharding strategy and shard key, feed generation (fan-out on write vs read), the realtime layer (WebSockets, long-poll), unique ID generation, or cache invalidation. Go deep on the one that drives the architecture, mention the rest.

WHAT TO SAY: "The interesting part here is the timeline. There are two approaches — fan-out on write versus fan-out on read — and the right answer depends on the celebrity problem. Let me work through both and pick."

Phase 6 — Identify bottlenecks & scale

WHAT: Now attack your own design. Where does it break at 10×? The moves are a fixed toolkit: add caching for hot reads, read replicas to spread read load, sharding when one DB can't hold the data or the writes, a CDN for static/media, and queues to absorb write spikes. Then hunt single points of failure (SPOFs) — every box that exists exactly once is a SPOF — and hotspots (the celebrity, the viral tweet, the one shard everyone hits).

WHAT TO SAY: "The single DB is both a SPOF and the read bottleneck. I'll add replicas for reads and promote a replica on failure. The write master becomes the next limit around X writes/sec, so I'll shard by user ID. The hotspot risk is a viral item — I'll handle that with a dedicated cache entry and maybe request coalescing."

Phase 7 — Wrap up

WHAT: Recap the key trade-offs you made, list what you'd do with more time, and name the failure modes and how the system degrades. This is a 90-second closing that leaves the interviewer with a clear picture of your judgment.

WHAT TO SAY: "To recap: I chose eventual consistency on the timeline to keep reads fast — the trade-off is a few seconds of staleness, which is fine for this product. With more time I'd detail cache invalidation and the analytics pipeline. If the cache tier dies, reads fall back to replicas and get slower but don't fail — that's graceful degradation, which is what I'd optimise for."

The building-blocks toolkit

Parts II–VII gave you a workshop full of components. In a design, you reach for the right block rather than invent one. This table is your reference — what each block is for, so you can name it in the right phase:

The meta-advice that runs through every case study

The framework is the skeleton; these habits are the muscle, and they apply to all seven chapters ahead:

• Drive the conversation. Own the agenda. Propose the next phase before you're asked. Passivity reads as junior.
• Think out loud. The interviewer scores what they hear. Narrate the search, not just the destination.
• State assumptions and trade-offs explicitly. "I'm assuming reads dominate; that buys cheap reads at the cost of write complexity." Every decision has a cost — name it.
• Start simple, then scale when pushed. Draw the one-server version first. Add complexity only when a number or a follow-up forces it. Premature sharding is a red flag, not a flex.
• Manage the clock. Say your time budget out loud. If you're overrunning a phase, flag it and move.
• Don't rabbit-hole. Depth is good; getting stuck perfecting one corner while the rest of the system stays blank is not. Timebox the deep dive.

Common Mistakes

• Skipping the framework under pressure. Panic makes people abandon structure and start drawing. The framework is most valuable when you're nervous — lean on it harder, not less.
• Estimating, then ignoring the estimate. Computing QPS and storage in Phase 2, then designing as if you never saw them. The numbers exist to drive Phases 4–6; use them.
• Front-loading complexity. Reaching for shards, microservices, and Kafka in Phase 4 before any number justifies them. Start simple; scale in Phase 6 when pushed.
• Rabbit-holing in the deep dive. Spending 20 minutes perfecting one component and never reaching bottlenecks or wrap-up. Timebox it and say so.
• Solving all fifty features. Refusing to scope in Phase 1, then designing a shallow version of everything instead of a deep version of the core three.
• Reaching for the wrong block. "Add a cache" when the bottleneck is writes (a cache helps reads), or a search index when a simple index on the DB would do. Know what each block is for.
• Silent design. Doing all seven phases in your head and presenting only the answer. If the interviewer didn't hear your reasoning, it didn't happen.

Interview Corner

Chapter Summary

• The design framework is a repeatable seven-phase method — clarify → estimate → API & data model → high-level design → deep dive → bottlenecks & scale → wrap up — that every case study in Part VIII applies.
• Each phase has a WHAT (the work) and a WHAT TO SAY (the sentence that signals it) — the interviewer scores what they hear, so narrate every phase.
• Phase 2's numbers drive Phases 4–6: read/write ratio, QPS, storage, and bandwidth decide whether you need caches, replicas, shards, and CDNs — never design against numbers you didn't compute.
• The building-blocks toolkit (LB, cache, CDN, SQL/NoSQL, replication, sharding, queue, search index, blob store, pub/sub) is a catalogue you reach into — know what each block is for and when to reach for it.
• Start simple, scale when pushed: draw the one-server version first and add complexity only when a number or a follow-up forces it — over-engineering is as much a red flag as under-designing.
• The meta-habits carry every design: drive the conversation, think out loud, state assumptions and trade-offs, manage the clock, don't rabbit-hole. It's a dialogue.
• A memorised answer is brittle; an internalised method bends — which is why the next seven chapters teach the framework applied, not pictures to copy.

Editorial reflection — the candidates who look effortless in a design round are almost never the ones who know the most. They're the ones who never have to decide what to do next, because a framework decides it for them — which frees every ounce of their attention for the actual problem in front of them. That is what a method is for. Not to replace thinking, but to hold the scaffolding steady so your thinking has somewhere to stand. Learn these seven phases until they're boring, until you could run them half-asleep. Then, when the prompt is impossible and the clock is loud, you'll be the calm one — not because you memorised the answer, but because you brought the axe, already sharp.