Module 01 · Lesson 02

The delivery framework: six moves, every time

Clarify, estimate, contract, design, deepen, close. Same order for every prompt.

Beginner 11 min read Updated 2026-11-01

What you will be able to do

  • Run the six phases in order on any prompt
  • Allocate the 45 minutes of design time across the phases
  • Say a transition sentence that keeps the interviewer oriented
  • Recognise the specific failure each phase is designed to prevent
  • Work one prompt end to end from clarify to wrap-up

Why a fixed order

Under time pressure, candidates improvise, and improvised rounds reliably fail the same way: a beautiful diagram that answers the wrong problem. A fixed order protects you from that. It also makes you legible — an interviewer who knows which phase you are in can follow a round without effort, and can see the moment you move from breadth to depth.

The framework is six phases. The names change between companies; the underlying moves do not.

One breath per phase
Before each phase begins, say its name out loud and what you are about to do. Six sentences total. They cost 30 seconds and give the interviewer a map of the last 45 minutes.

Phase 1 — Clarify (5 minutes)

Goal: turn one vague sentence into a list of features, a list of non-goals, and a scale. Ask questions whose answers change the design, and skip the ones that do not.

Questions worth the minutes
AskBecause it decides
Who uses this, and what is the one action they must be able to do?The feature set, and therefore which components exist at all
What is the read to write ratio?Cache strategy on one side, queue and partitioning on the other
How fresh must the data be — milliseconds, seconds, or is a minute fine?Strong consistency versus replicas and eventual consistency
Is this customer facing, or internal batch?Latency targets, and whether synchronous calls are acceptable
What is explicitly out of scope?Ten minutes of your remaining time

Then state the scope back in one sentence: "So the core is short links and redirects, custom aliases and analytics are stretch, and out of scope are billing, spam detection, and the UI." That sentence is your contract for the rest of the round.

The failure this phase prevents
Designing the authentication flow for a system whose hard part is write amplification. If you did not clarify, you cannot know which part is hard — and you will spend the depth budget in the wrong place.

Phase 2 — Estimate (3 minutes)

Goal: convert the product description into numbers you can reuse in every later decision. Four figures are enough: requests per second, storage per year, bandwidth at peak, and the read/write split. Round aggressively — 86,400 seconds per day is 100,000, and 100,000 is the only number you need.

Given: 100M new links per month, 10:1 read to write.

writes  = 100M / (30 days x 100k s/day)  ~= 33 per second
reads   = 10 x 33                        ~= 330 per second
storage = 100M x 0.5 KB x 12 months      ~= 600 GB per year

Peak is usually 3-5x average, so design the write path for ~150/s.

Say the numbers with their consequence attached, not on their own: "330 reads a second is nothing for Postgres, but the read path is 10x the write path, so a cache in front of it is the obvious first lever." An estimate with no decision attached is decoration.

The failure this phase prevents
Designing for a scale you invented. If you never estimate, you will reach for a globally distributed database when a single Postgres instance would carry the load, and the interviewer will read that as judgement you do not have.

Phase 3 — Entities and contract (5 minutes)

Goal: agree on the nouns of the system and the calls that touch them, before any boxes are drawn. This is the cheapest place to discover a misunderstanding, because nothing has been built on top of it yet.

  1. Entities: the four to six things the system stores, with their key fields. Link { code, targetUrl, ownerId, createdAt, expiresAt }.
  2. The one or two access patterns that matter: read a link by code; list a user's links by creation date.
  3. The API: five calls at most, each with a request and a response shape. POST /links, GET /{code}, GET /links?user=, DELETE /{code}, GET /{code}/stats.
  4. Say which of these is on the hot path. For a shortener it is the redirect, so that is the one to optimise later.

The API is the highest-value five minutes in the round. Every box you draw afterwards exists to serve one of these calls, and the interviewer can now check your design against something concrete.

Phase 4 — High-level design (15 minutes)

Goal: a diagram where every functional requirement from phase 1 is satisfied by some path through the boxes. Correct and complete matters here; fast and scalable does not yet. A design that works end to end and clearly will not scale is a better answer than one that scales but drops a feature.

Draw the request path, not the architecture diagram
Start from the client and follow one request to storage and back. Trace the redirect: client, DNS, load balancer, app server, cache, database. Narrate it as you draw.
Add the components the requirements force
Analytics needs somewhere to write counts — that is a stream and a worker. Custom aliases need a uniqueness check — that is an index. Add nothing that no requirement asked for.
Mark the data flow for writes separately
The write path and the read path almost always differ. Drawing both on the same diagram is where most candidates discover that their cache is never populated.
Check every requirement against the diagram
Read your phase 1 list and point at the part of the drawing that satisfies each item. Whatever you cannot point at is either missing or out of scope — say which.
The failure this phase prevents
Architecture theatre: a diagram full of familiar logos where nothing connects. If you cannot trace a request through it, neither can the interviewer.

Phase 5 — Deep dives (15 minutes)

Goal: two or three hard parts solved properly, each with options, a choice, a cost and a number. Pick them by risk, not by interest — the thing most likely to break under the stated scale is the thing to solve.

For a shortener, the three candidate dives are code generation without collisions, the hot read path, and analytics that cannot slow redirects down. Choose two and say why you chose them: "Collisions and the redirect hot path are where this breaks at scale, so let me spend the time there rather than on the admin UI."

What a good deep dive contains
MoveSounds like
Name the options"For codes I could hash the URL, use a counter encoded in base62, or generate random strings and check."
Pick one and justify"Counter plus base62 is shortest and never collides, but it leaks volume and forces a central sequence."
Name the cost"That means one write bottleneck; I would hand out ID ranges per app server so the counter is not on the hot path."
Attach a number"Seven base62 characters gives 3.5 trillion codes, so we never run out."
Name what breaks it"If a range is lost with a crashed server we leak codes — acceptable, since codes are cheap."

Phase 6 — Wrap-up (5 minutes)

Goal: show you know where your own design is weakest, and what you would do next with more time. Three sentences do it:

  • Recap: "We scoped short links with analytics, chose counter-based codes with per-server ranges, cached the redirect path, and streamed click events."
  • Weakest part: "The analytics pipeline is the least proven piece — at 100k events a second I would want to verify consumer lag before trusting it."
  • Next with more time, or your questions for them: "Next I would add abuse detection and expiry sweeps. Happy to go deeper on anything."
Q. The interviewer jumps in at minute 12 and asks about sharding. Do I abandon the plan?
No — follow them, then return. "Happy to go there; let me spend two minutes on sharding and then come back and finish the API." The framework is your default, not a contract you force on the interviewer.
Q. Do I have to estimate for every prompt?
Yes, but the depth varies. A rate limiter needs request volume and the size of the counter state; a collaborative editor needs concurrent sessions. Two minutes of arithmetic beats an hour of designing for the wrong scale.

Worth remembering

  • The order is fixed: clarify, estimate, contract, high-level design, deep dives, wrap-up. The clock within it is flexible.
  • Phases one to three take 15 minutes and remove most of the ambiguity. The following 30 are where depth is scored.
  • Every transition gets a sentence: "That covers scope, so let me estimate scale and then draw the design."
  • The wrap-up is not filler. Naming the weakest part of your own design is a scored move.

Checkpoint

Answer all 3 questions to finish the lesson.
1. What is the correct order of the six phases?
Scope comes before numbers, numbers before the contract, the contract before the diagram, and depth only once something complete exists to deepen.
2. Which phase most reliably removes a misunderstanding before any design work is invested?
Naming entities and writing the five calls is the cheapest checkpoint: the interviewer can disagree with a concrete API in seconds, whereas the same disagreement after the diagram costs you the design.
3. During phase 4 you realise one functional requirement is not yet satisfied by any box. What is the right move?
Phase 4 exists so that completeness can be checked requirement by requirement. Naming the mapping keeps the design traceable; silently dropping the requirement is the failure mode this phase is designed to catch.
← PreviousHow a system design interview works