The 4-step interview framework

The four-step framework is a fixed order of operations for a design round: pin the requirements, size the system, draw it, then go deep. What it buys is coverage under a clock — you finish with a whole design that has a scale story and two defended decisions, instead of a beautifully detailed fragment of one.

What it costs is flexibility: run it rigidly and you produce the same generic diagram for every prompt and miss whatever made this one interesting. Treat it as a default order rather than a script — part of what's being graded is knowing which step this prompt doesn't need. What is system design? is the vocabulary this procedure assumes; nothing here re-teaches it.

The cue is the absence of a spec, not the presence of a technology: an open-ended prompt with a scale word in it and no acceptance criteria — design X for N users. Nobody will tell you when you are done, so the framework's real job is to supply the missing structure before the silence does. Meta runs the round in two flavours, systems and product, and opens both with clarifying questions about scale, latency and storage — the framework's first step under a different name.

Before the first question, put four headings on the board with their budgets — Requirements (5), Estimates (5), High-level design (15), Deep dives (15) — and leave a blank block under the first for functional bullets, non-functional numbers, and a labelled assumption list. The headings do two jobs: they hold the plan where you can both see it, so a transition costs three words rather than a sentence, and an empty block under Estimates is a visible prompt to ask whether the arithmetic is wanted at all.

The arithmetic is the part worth rehearsing, because it has to run in your head while you talk. Four shortcuts cover almost every prompt:

A day is ~10⁵ seconds. 86,400 rounds to 100,000, so per day ÷ 10⁵ = per second — 100M/day is ~1,000/s. The 16% error is far inside the precision anything else here deserves — the worked run below divides by the exact 86,400 and reports ~1.2k, and either is a fine interview answer.

1M/day ≈ 12/s, and scale from there. Reads = writes × the ratio, so pin the write rate first and never estimate reads directly.

For bytes, round the record to a power of ten, then multiply by the daily count. 100M × 500 B = 5 × 10¹⁰ = 50 GB/day; × 365 for a year. A year is ~3 × 10⁷ seconds if you need to go the other way.

Carry one or two significant figures. "~1.2k writes/s" is the answer; 1,157.4 is the same answer with two extra chances to slip under pressure.

The design below is deliberately thin — the subject is the procedure, not the shortener.

Step 1, five minutes. Functional: create a short link for a target URL; redirect a short link to its target; optionally expire a link and count clicks. Then the assumptions, each said out loud and labelled as an assumption, because that is what makes it correctable:

A1 — 100M new short links created per day. A2 — reads outnumber writes 100:1. A3 — peak traffic is 2× average. A4 — a stored record averages ~500 bytes. A5 — links are retained for five years. A6 — a hot set of ~10M links (roughly a day of writes, or a Zipf head of about 1%) serves most reads.

A2, A3, A6 and the ~100-byte median target URL inside A4 are conventional interview assumptions with no published measurement behind them. Declared as assumptions they are fine; asserted as facts they collapse the moment someone asks where they came from.

Step 2, five minutes. Every row below is arithmetic over A1–A5 — except the last one.

Step 2's output is four decisions, not nine numbers.

Seven characters, not six. At 10⁸ writes a day a 6-character base62 space is exhausted in 568 days, so the key-generation scheme has to emit 7. This is the number that would have quietly broken the design in year two.

~91 TB at five years. That fits on one machine's disks, but not in its page cache — and no single machine serves 232k reads/s off it. That is what puts sharding and read replicas on the table, not the capacity number. The 50 GB a day is why a TTL or an archival tier is worth proposing before anyone asks.

5 GB hot set — so argue against a distributed cache. The top 10M links fit in a single node's memory — though at 232k reads/s it is throughput, not capacity, that decides how many nodes you end up with, and that is the number to say out loud. Start with one cache and defer consistent hashing until one of the two outgrows it. An estimate that buys you simplicity is the strongest use of this step; using a number to justify adding a component is the easy direction.

232k peak reads/s against ~1.2k writes/s. The read path is the system. caching and read replicas come before anything on the write side.

And then the last row — the only measured number in the table. The prompt as assumed is around 50× a real production shortener's published traffic, from over a decade ago. Nothing above is wrong; it is just downstream of A1–A5. The design follows from your assumptions, not from reality, which is exactly why you state them where the interviewer can push on them.

Step 3, fifteen minutes. Two endpoints: POST /links {url, ttl?} → {code} and GET /:code → redirect to target (see REST APIs for the contract side). Then four boxes — client → a load balancer → a stateless link service → a key-value store keyed by short code, with a cache in front of the read path. Everything interesting here is another lesson's: Database indexing for the lookup, rate limiting for the create endpoint, caching for the read path. Get agreement on the skeleton, then stop drawing.

Step 4, fifteen minutes. The hardest target here is read latency at 232k/s, so the deep dives come off it. How are codes generated without a coordination bottleneck? What does the cache do when a viral link misses in a thundering herd? What happens when the store outgrows one node? Two done properly beat four sketched.

Last minute. Name the two tradeoffs you took — one cache node rather than a distributed cache, a key-value store rather than a relational one — and what evidence would make you revisit each.

Rigidity, and it bites whenever the prompt's difficulty is somewhere the template doesn't look: a product-design prompt where scale was never in question and step 2 has nothing to compute, or a prompt whose whole difficulty lives in one deep dive. The mitigation is to shrink a step out loud, with a reason — "the scale here is obviously large and distributed, so I'll spend two minutes on estimates and put the rest into the data model". A shrunk step with a stated reason still reads as a decision; a skipped one reads as an omission.

The 5 / 5 / 15 / 15 split is ours; so is hoisting estimation into a step of its own, and on that second point the sources converge against us. ByteByteGo tells you to "communicate with your interviewer if back-of-the-envelope is necessary before diving into it". system-design-primer opens its worked solutions the same way. Hello Interview says to calculate only when it will directly influence the design, and folds the API contract into its own step besides. All three make estimation conditional.

We hoist it anyway, as a learning scaffold: dropping a step you can already execute is far easier than inventing one under time pressure. In a real interview, follow the sources — do the arithmetic when the number changes a decision, say which decision, and otherwise ask whether it is wanted at all.