system-design

The Framework: How to Drive a 45-Minute Design Round ⭐

The single most important chapter for interview success. A repeatable structure that turns a vague, open-ended question into a controlled, confident performance — so you never freeze or ramble.

Prerequisites: most of Parts 1-10; this is where you apply them Time to read: ~25 minutes

Why you need a framework

🚨 The interviewer says “Design Twitter” and starts a 45-minute clock. Without a plan, candidates do one of two things that lose points: freeze (not knowing where to start), or immediately draw boxes (jumping to a solution before understanding the problem). Both signal panic and inexperience.

A framework gives you a structure to fall back on, so you always know the next move. It converts an intimidating open question into a sequence of manageable steps. 🚨 The interview isn’t testing whether you know the “right answer” — it’s testing whether you can drive a structured design conversation, make reasoned trade-offs, and communicate clearly. The framework is how you demonstrate all three.

The framework: six phases in 45 minutes

Requirements       (5-8 min)   — what are we building, and how well?
Estimation         (3-5 min)   — how big is this?
API + Data Model   (5-7 min)   — the interface and the entities
High-Level Design  (8-12 min)  — the boxes and arrows; walk one read + one write path
Deep Dives         (10-15 min) — go 2-3 levels deep on what matters
Wrap-up            (2-3 min)    — bottlenecks, what you'd do with more time

🚨 The times are targets, not rigid — the interviewer may steer you, and you should follow their signals. But knowing the shape keeps you from spending 25 minutes on requirements and never reaching a design (the #1 time-management failure).

🎙️ Open by stating the plan — it signals you’ve done this before: “I’m planning to spend a few minutes on requirements and scale, then the API and data model, then the high-level design, and then go deep on the parts you’re most interested in. Does that work?” This one sentence makes you look like someone who has run design reviews.

Phase 1: Requirements (5-8 min) — the most under-valued phase

🚨 Most interviews are lost here, because candidates rush past it and design the wrong system beautifully. Slow down and scope aggressively.

Functional requirements — what does it do? Ask clarifying questions and narrow the scope:

“Design Twitter” is enormous. What’s the core? Posting tweets and viewing a feed? Let’s focus there and treat DMs, search, and ads as out of scope unless you want them.
🚨 Explicitly state what’s OUT of scope — this shows judgment and buys you time to do the core well. “I’ll focus on posting and the feed; I’ll note DMs and search as extensions but not design them unless you’d like.”

Non-functional requirements — how well? These drive the architecture more than the features:

Scale — how many users, requests/second, data volume?
Latency — is 200ms fine, or does it need to be 10ms?
Availability — how many nines?
Consistency — where does strong vs eventual matter?
Read/write ratio — 🚨 ask this; it determines the whole strategy.

🎙️ The strong questions to ask (→ Requirements Gathering): “What’s the scale? What’s the read/write ratio? What latency do we need? Where does consistency matter — can the feed be slightly stale?” Each answer meaningfully changes the design.

🚨 Write the requirements down (on the whiteboard/doc). It anchors the conversation and lets you refer back (“we said the feed can be eventually consistent, so…”).

Phase 2: Estimation (3-5 min) — derive the architecture from numbers

🚨 Do the back-of-the-envelope math — it tells you what the design must handle, and it’s a strong signal. Compute: peak QPS, storage/year, bandwidth.

And use the numbers — the point isn’t the arithmetic, it’s what it tells you:

“That’s 450,000 reads/second — no single database serves that, so we need a cache and precomputation.”
“550 TB over 5 years — that requires sharding.”
“Media is 200× the text data — that’s object storage + CDN, not the database.”

🎙️ “Let me size this — 150M daily actives, posting twice and reading 100 tweets a day, gives ~3,000 writes/second and 150,000 reads/second. That 50:1 ratio tells me this is read-heavy and I should design for reads: cache and precompute the feed.”

Narrate every step and state assumptions. → Estimation in Interviews

Phase 3: API + Data Model (5-7 min)

API — define the core endpoints (3-6, not exhaustive):

POST /tweets          {text}          → create
GET  /feed?cursor=... {}              → the timeline (paginated!)
POST /follow          {user_id}

→ API Design. Mention pagination and idempotency where relevant — quick signals.

Data model — the core entities and how they relate:

users(id, handle, ...)
tweets(id, user_id, text, created_at)
follows(follower_id, followee_id)

Note the access patterns and which database fits.

🚨 Keep this crisp — it’s a stepping stone to the design, not the main event.

Phase 4: High-Level Design (8-12 min) — the boxes and arrows

Draw the architecture: clients → load balancer → services → cache → databases → queues. → Drawing Diagrams

🚨 The key move: walk one write path and one read path end to end. Don’t just draw boxes — trace a request through them:

“A user posts a tweet: it hits the LB, the tweet service writes to the database, and publishes an event to fan out to followers’ feeds…”
“A user opens their feed: the request hits the LB, checks the feed cache, which was precomputed…”

Justify every box. 🚨 Every component must earn its place — “I’m adding a cache here because reads are 50× writes and the feed is read repeatedly.” A box with no justification is a weakness.

Phase 5: Deep Dives (10-15 min) — where senior is separated from mid

🚨 This is the phase that most differentiates candidates. The interviewer picks (or you offer) 2-3 components and you go three levels deep. → Deep Dives

Offer the interesting one: “The most interesting part here is the feed generation — should I go into fan-out?” Steering toward your strength is good.
Go three levels: not “we’ll use a cache” (level 1), but “cache-aside, 5-min TTL, delete-on-write to avoid the race, jittered TTL to prevent avalanche, and here’s what happens when the cache is down” (level 3).
Handle the hard cases: the celebrity fan-out problem, the hot key, the consistency edge.
Discuss trade-offs explicitly — “I chose fan-out-on-write, which costs us write amplification but makes reads cheap; the alternative was fan-out-on-read…” → Trade-off Vocabulary

🎙️ Follow the interviewer’s hints. If they keep asking “what if this fails?” they’re handing you points — take them.

Phase 6: Wrap-up (2-3 min)

Identify bottlenecks and what breaks at 10× — “The first thing to break as we grow is the feed fan-out for celebrities; I’d address that with a hybrid approach.”
What you’d do with more time — shows self-awareness: “With more time I’d design the search system and the notification delivery.”
Ask if there’s anything they want to explore.

The meta-rules (what actually scores)

🚨 Beyond the phases, these behaviours determine the outcome:

Communicate constantly. 🚨 Narrate your thinking — a silent candidate can’t be evaluated. Think out loud, especially when stuck.
Drive, but collaborate. Lead the design, but treat it as a conversation — check in, respond to signals. It’s a collaborative design session, not a monologue or an exam.
Make trade-offs, don’t recite. 🚨 Every real decision has a cost. Saying “I’d use X, which costs us Y, but that’s acceptable because Z” is the single strongest thing you can do. → Trade-off Vocabulary
Start simple, evolve under pressure. → 1 to a billion. Don’t draw the final complex architecture; build up.
Manage the clock. Don’t spend 25 minutes on requirements. Keep moving.
Handle “I don’t know” gracefully. → Handling Uncertainty. “I’m not sure of the exact answer, but here’s how I’d reason about it…”

The common failure modes

🚨 (Full list in Common Mistakes.) The big ones:

Jumping to a solution without requirements.
Never getting to a design (stuck in requirements/estimation).
Boxes with no justification.
No trade-offs — reciting components.
Silence — not narrating.
Ignoring failure — only the happy path.
Over-engineering — sharding/microservices for a small system.

🎙️ Soundbites

“I’m planning to spend a few minutes on requirements and scale, then the API and data model, then the high-level design, and go deep on the parts you’re most interested in — does that work?”
“Before I design anything, let me pin down the scale, the read/write ratio, and where consistency matters — those decide most of this. And I’ll scope aggressively: I’ll focus on the core and note the rest as extensions.”
“That’s 450,000 reads per second — no single database serves that, so caching and precomputation aren’t optimizations here, they’re structural. Let me design for that.”
“Let me walk one write path and one read path through this so you can see how the pieces fit.”
“I chose fan-out-on-write, which costs us write amplification but makes reads cheap. The alternative was fan-out-on-read — I’d revisit that for celebrities, where the write cost explodes.”

🛠️ Try it

1. Run a timed mock, out loud, with the phases. Pick a case study, set a 45-minute timer, and drive it through all six phases — out loud, with a drawing tool. Do NOT read the solution first. Then compare to the writeup and grade yourself with the self-grading checklist. The gap between your attempt and the writeup is your study list.

2. Practice just the opening. For ten different problems, practice only the first 8 minutes — stating the plan, gathering requirements, scoping. The opening sets the tone, and nailing it repeatedly makes it automatic.

3. Practice the trade-off sentence. For every design decision you make, force yourself to complete “I’d use X, which costs us Y, but that’s acceptable because Z.” Until this is reflexive, you’ll recite components instead of reasoning.

4. Do mocks with a real human. Solo practice can’t reproduce the pressure of someone watching you be stuck. From Week 8 onward, do timed mocks with a partner (Pramp, interviewing.io, a study buddy). → Mock Interviews

Check yourself

1. What is the interview actually testing, and why does that make a framework valuable?

The design interview isn't testing whether you know the single "correct" architecture for the problem — there isn't one, and the interviewer usually knows the space far better than a 45-minute conversation could reveal. It's testing whether you can *drive a structured design conversation*: gather and scope requirements, estimate scale and derive implications from it, propose a reasonable architecture and justify each component, go deep on the hard parts, make explicit trade-offs, handle failure, and communicate clearly throughout — the actual skills of the job, simulated in miniature. A framework is valuable because it gives you a repeatable structure to demonstrate all of those, so an intimidating open-ended prompt ("Design Twitter") becomes a sequence of manageable steps where you always know the next move. Without it, candidates freeze (not knowing where to start) or jump straight to drawing boxes (solving before understanding), both of which signal panic and inexperience and prevent you from showing the reasoning that's actually being evaluated. The framework isn't a script to recite — it's scaffolding that ensures you cover requirements, estimation, design, depth, and trade-offs in a controlled way, so your judgment and communication get a chance to show.

2. Why is the requirements phase the most commonly under-valued, and how do you do it well?

It's under-valued because it feels like preamble — candidates are eager to get to the "real" design (the boxes and arrows) and rush through or skip clarifying the problem, so they end up designing the wrong system, beautifully. But the requirements phase is where interviews are most often lost, precisely because the non-functional requirements (scale, latency, availability, consistency, read/write ratio) *drive the architecture more than the features do* — a chat app tolerating 2 seconds of delay and a trading system requiring 2 microseconds are the same feature and completely different systems, and you can't know which you're designing without asking. Doing it well: **scope aggressively** — an open prompt like "Design Twitter" is enormous, so narrow to the core (posting and the feed) and *explicitly state what's out of scope* (DMs, search, ads), which shows judgment and buys time to do the core properly. **Ask the questions that change the design** — what's the scale? the read/write ratio? the latency target? where does consistency matter (can the feed be stale)? — and note how each answer shifts the approach. **Write the requirements down** so they anchor the conversation and you can refer back to them. Slowing down here, rather than rushing to draw, is counter-intuitively how you demonstrate seniority — you design the *right* thing.

3. Why should you walk a read path and a write path through your high-level design?

Because a diagram of boxes and arrows only shows *structure*; walking a request through it shows the system actually *works* and demonstrates that you understand how the components interact, which is what the interviewer is evaluating. Drawing "load balancer → service → cache → database" is easy and shallow; tracing "a user posts a tweet: it hits the load balancer, routes to the tweet service, which writes to the database, publishes an event to a queue, and workers fan it out to followers' feed caches" proves you know the data flow, the ordering, where the writes go, and how the async pieces connect. Walking *both* a write path and a read path is important because they're usually different (a write updates the source of truth and triggers downstream effects; a read hits caches and precomputed data), and the interesting design decisions often live in that difference — for a feed, the write path is where fan-out happens and the read path is where the precomputed feed is served. It also naturally surfaces the justification for each component ("we hit the cache here *because* reads are 50× writes") and reveals gaps (if you can't trace a path cleanly, a piece is missing). It turns a static picture into a working system in the interviewer's mind, which is far more convincing than the picture alone.

4. Why do deep dives most differentiate candidates, and what does "three levels deep" mean?

Deep dives differentiate candidates because the high-level design (boxes and arrows) is something most prepared candidates can produce — it's largely pattern-matching to a known architecture — whereas going deep reveals whether you actually *understand* the components or just know their names, and understanding is what separates senior from mid-level. "Three levels deep" means progressively refining a decision past the surface: **level one** is naming the component ("we'll use a cache"); **level two** is the concrete configuration ("cache-aside, 5-minute TTL, keyed on user ID"); **level three** is the failure modes, edge cases, and second-order effects ("delete-on-write rather than update to avoid the race where two concurrent writers leave the cache permanently wrong, jittered TTLs to prevent a synchronized avalanche, and here's what happens when the cache is down — we can't send 100% of traffic to the database, so I'd add a circuit breaker and serve degraded"). Level one is what everyone says; level three is what demonstrates you've operated these systems and thought about how they break. The interview rewards depth on the parts that matter — the feed generation, the hot-key handling, the consistency edges — so you either offer the interesting component yourself ("the most interesting part is the feed fan-out — shall I go into that?") or follow the interviewer to where they want depth, and then you keep refining past the obvious answer into the trade-offs and failure handling that show real understanding.

5. What behaviours, beyond the six phases, actually determine whether you pass?

The phases are scaffolding; these behaviours are what's scored within them. **Communicate constantly** — narrate your thinking out loud, because a silent candidate can't be evaluated and silence reads as being stuck or lost; think aloud especially when you *are* stuck, so the interviewer sees your reasoning process. **Drive but collaborate** — lead the design confidently, but treat it as a conversation, checking in and responding to the interviewer's signals, because it's a collaborative design session, not a monologue or a written exam. **Make trade-offs rather than reciting** — every real decision has a cost, and articulating "I'd use X, which costs us Y, but that's acceptable because Z" is the single strongest signal you can give, distinguishing reasoning from name-dropping components. **Start simple and evolve under pressure** rather than drawing the final complex architecture up front, which shows you understand that scaling is a journey and resist over-engineering. **Manage the clock** — don't spend 25 minutes on requirements and never reach a design (the top time-management failure). And **handle "I don't know" gracefully** — reason from principles out loud rather than freezing or bluffing. Interviewers are evaluating judgment, communication, and how you think under uncertainty at least as much as the specific architecture, so these behaviours often matter more than getting every technical detail "right."