How to approach a system design interview

A system design interview gives you one vague sentence, “design a ticketing system”, and about 45 minutes. There is no single right answer. So the interviewer is not checking yours against a key. They are collecting evidence about how you reason. Do you find what matters? Do you build something that works? Do you go deep where it counts? And do you keep them with you while you do it? A framework makes sure that evidence exists before the time runs out.

This page describes the framework every worked problem on this site follows. It covers why each step is there, how long it gets, and where candidates lose the round. Each step links to real examples in the problem pages, so you can see it done in full.

The problem it solves

Take the Ticketmaster prompt and two candidates.

The first draws a load balancer, an API gateway, six microservices, Kafka, Redis, Cassandra and a CDN by minute four. It looks like a production system. Then the interviewer asks why Cassandra, and the answer is “it scales”. Asked how two fans are kept from buying the same seat, the answer is “a distributed lock”. At minute 38 the candidate is still explaining the gateway.

The second asks four questions, and learns the one that decides everything: 2 million people arrive at 10:00 for 50,000 seats. Two minutes of arithmetic turn that into about 25,000 hold attempts a second, on one event’s rows. The first drawing is one service and one database, with a conditional update. Then the candidate shows why that database cannot take 25,000 attempts a second. So they add a waiting room that admits 2,000 people a minute. That brings the hold rate down to about 100 a second. Ten minutes go to the locking deep dive, and to the case where payment succeeds after the hold expired.

The second diagram has fewer boxes and gets the hire. Every box on it was forced by a number the interviewer watched being derived. The first candidate’s boxes might all be reasonable, but nothing in the round showed why, so none of them count.

That is the problem a framework solves. Interviewers at large companies grade roughly the same four things, whatever their rubric calls them:

What is graded	The evidence that earns it	Where it comes from
Problem navigation	You found the requirements and the number that decide the design, and named the hard part	Requirements, estimates
Solution design	A design that works end to end and meets the stated requirements	API, data model, simplest design, stages
Technical depth	You know how the pieces work and fail, with options, numbers and tradeoffs	Deep dives, failure
Communication	The interviewer could follow every step and steer when they wanted to	Checkpoints throughout

Without a plan, candidates overspend on whatever they are comfortable with, usually requirements or a big diagram. Then the bell rings before the deep dives, where depth is graded. A fixed sequence also frees attention. You never spend a minute wondering what to do next.

How it works

The framework has nine moves: requirements, estimates, API, data model, the simplest design, stages forced by numbers, deep dives, failure, and a wrap-up. The problem pages write it out as 12 sections, because consistency, operations and the tradeoffs summary get sections of their own. In a 45 minute round those fold into the deep dives, the failure pass and the wrap-up.

The framework every worked problem follows

Scroll or pinch to zoom, drag to pan

• Color key
• Service

The loop in the middle is the part most candidates skip. A design does not arrive finished. It starts as the smallest thing that meets the functional requirements, and each component after that appears only because a number broke the previous version.

Step 1: Clarify, then pin the requirements

The prompt is vague on purpose. Finding out what matters is the first thing being graded.

Functional requirements are what users can do, written as verbs: create a short link, follow it, delete it, see click counts. Three to five is right. Mark the ones that are later or out of scope, with a reason, so the interviewer knows you saw them and chose. A list of twelve features signals that you cannot prioritize.

Non-functional requirements are the properties the system must have, and each one needs a number or a named guarantee. Adjectives cannot drive a design. Numbers can.

Vague	Pinned	What it decides
“Highly available”	99.99% for redirects (52 minutes down a year), 99.9% for creation	Which path gets replicas, failover, regions
“Low latency”	p99 redirect under 20 ms of server time	Whether the read path may touch a database
“Scalable”	100 million new links a month, 100 reads per write	Cache or not, one primary or many
“Consistent”	The creator reads their own link at once; others within a second	Where reads may go to a replica
“Durable”	A created mapping is never lost	Synchronous replication on the write path

Pin numbers by proposing them, not by asking open questions. “How many users?” invites “you tell me”. “I’ll assume 100 million links a month and 100 reads per write, is that in the right range?” gets a yes or a correction. Either way, you have a number. Ask only the questions whose answer changes the design. The URL shortener writes each question next to how a different answer would change it. If you cannot fill that column, the question is not worth the time.

Then name the hard one: the requirement every later decision is judged against. For the URL shortener it is the redirect path, which carries 99% of the traffic and the strictest availability target. For Ticketmaster it is the hold under contention. Naming it tells the interviewer where you will spend your depth.

Say this out loud

Before I draw anything, I want the scale, the read to write ratio, and whether clicks are counted. Those three decide how codes are generated, which redirect status I return, and where the caching effort goes.

Budget: about 6 minutes, questions and requirements together.

Step 2: Estimate only what changes a decision

An estimate is worth its time when its result flips a decision. One database or several? A cache or none? Does the data fit in memory or not? Push or pull? Every estimate should end in a sentence that starts “so we”. Four numbers in four minutes is the usual bar.

The number that matters differs by problem, and finding it is the skill:

Problem	The number that decides	The decision it flips
News feed	Feed writes from fan-out on post, about 690,000 a second	Push for most users, pull for celebrities
Video streaming	Egress cost, about 2.7 cents per hour watched	Design around bytes delivered: CDN, ISP caches
Chat	Concurrent connections, not messages a second	Gateways that hold sockets, a session registry
Typeahead	Keystrokes, not searches, and an index that fits in RAM	Precomputed answers in every server
Ticketmaster	2 million people for 50,000 seats at one moment	Admission control, not more servers

When to shorten it. Some problems have small numbers, and saying so is the estimate. The payment system peaks at about 600 payments and 3,600 database writes a second. So it needs a handful of servers and one primary, and can spend everything on correctness. In the stock exchange, storage is the one number that does not matter. The message rate against one thread’s speed does. Skipping estimates entirely means nothing later can force a stage. Then every box becomes an assertion.

When to stop. Round to one significant figure. The third digit never changes a design. Ten minutes of storage arithmetic that ends in “so it’s big” is the most common way to burn the time deep dives need. The arithmetic itself, powers of ten, seconds in a day, latency and throughput figures, is on the estimation page.

Budget: about 4 minutes, 2 to 3 when the numbers are small.

Step 3: API and data model, from access patterns

The API names the core operations with their request and response shapes, and makes the one or two protocol decisions that matter. For the URL shortener it is 302 versus 301, a choice tied to the analytics requirement. For chat it is how the server pushes to the phone, which makes it a WebSocket. Writes that a client may retry get an idempotency key. The management endpoints a real product needs can be one line. The details of protocols, pagination and versioning are on the API design page.

The data model starts from access patterns, not tables. List each query with its frequency and shape: point read by key, range scan by time, or append only. The schema and keys follow. The URL shortener’s access pattern table makes the hot path a single key lookup. And it shows that click events belong somewhere else entirely. The database choice comes last, justified by those patterns. Choosing a database covers the options.

Budget: about 7 minutes for both. Three endpoints and one table with its keys is often enough.

Step 4: The simplest design that works

Draw the smallest design that meets every functional requirement: usually one service and one database. Walk one write and one read through it. Then name its flaws yourself, in the order you will fix them.

The URL shortener’s stage 1 is one server and one table, with three deliberate flaws stated up front. There’s a shared sequence every create waits on, guessable codes, and a database read on every click. The notification system starts by sending inline, which is wrong in an instructive way. The stock exchange starts with one matching engine in memory. That turns out to be the core of the final design too.

This step proves you can build something end to end. It gives the numbers something concrete to break. And it guards against over-designing, because every later box has to point at the flaw it fixes.

Budget: 2 to 3 minutes, at the start of the high level design block.

Step 5: Let the numbers force each stage

Put the estimates against the simple design and ask what breaks first. Each stage names the bottleneck with its number, adds the one component that fixes it, and states what that component costs. Then ask again. The URL shortener grows like this:

Each stage of the URL shortener, and the number that forced it

Scroll or pinch to zoom, drag to pan

• Color key
• A stage

Every arrow is a sentence the interviewer can check. That is the difference between a design and a recited diagram. The partitioning stage even names its trigger: about 2 TB, a replica rebuild over an hour, or cache CPU above 60%. The news feed moves celebrities to pull only when the fan-out math says pushing their posts costs more than it saves.

Stop when the numbers stop. If nothing in the estimates breaks the current design, adding a component is over-design. Multi-region for a system with one region’s worth of users, or sharding a 600 GB table, costs operational risk. And it buys nothing the interviewer asked for.

Budget: the rest of the 8 minute design block (about 5 minutes) goes to the stages that reach a working v1. Then about 6 go to the stages that 10x load forces.

Step 6: Deep dives

Deep dives are where Senior and Staff are decided. In a 45 minute round there is time for two or three, about 10 minutes in all.

A good deep dive is specific to this problem’s crux, has real alternatives, and can be settled with a number. The worked problems open with a short list of what makes each one hard, and the deep dives follow from it. Each one has the same shape:

1. State the problem precisely. “Two fans click the same seat within a millisecond” beats “concurrency”.
2. Lay out two to four options with what each wins and loses.
3. Pick one with a number. Ticketmaster’s locking deep dive uses Little’s law. At 25,000 attempts a second, pessimistic locks keep about 750 connections busy. A conditional update keeps about 75.
4. Say how it fails and what the pick gives up.

Other examples are worth studying too. The URL shortener’s viral link shows a hot key is a one-node problem, not a total-load problem. And the message queue’s exactly once gives a precise answer to a question most candidates answer loosely.

Budget: about 10 minutes, more whenever the earlier steps ran short. Problems whose hard part is a race or a guarantee take 12 to 14 (see problem shape).

Step 7: Failure, then the wrap-up

Failure is a pass over the final drawing. For each component: what happens when it dies, how you find out, and what users see. The strongest answers separate the paths. In the URL shortener, a primary database failure stops link creation for about 30 seconds. Meanwhile, redirects carry on from caches and replicas. The failure table lists every component that way. Where it matters, add which operations need strong consistency, and which can be eventual. The same problem’s consistency table does this.

The wrap-up takes one or two minutes. Name the three to five decisions that shaped the design, and what each gave up. Then say what you would do next, at 10 times the load or with more time. The tradeoffs summary of each problem is that answer in table form.

Budget: about 4 minutes for both. If time is short, the failure of the one critical component is the part to keep.

Spending the 45 minutes

The budget below is the one the worked problems use. Each problem’s interview walkthrough adjusts it slightly.

Minutes	Phase	What exists at the end
0 to 6	Clarify and requirements	Functional list, non-functional numbers, out of scope, the hard one
6 to 10	Estimates	Three to five numbers, each with its “so we”
10 to 17	API and data model	Core endpoints, access patterns, keys, database choice
17 to 25	Simplest design, first stages	A working v1, each component tied to a requirement
25 to 31	Scaling stages	The design at 10x, each fix tied to a bottleneck
31 to 41	Deep dives	Two or three hard parts, settled with options and numbers
41 to 45	Failure and wrap-up	What breaks and what users see; decisions and their costs

Two clock checks matter more than the rest. The first design should be on the board by about minute 17. And deep dives should start by about minute 31. If either slips by more than a few minutes, compress whatever comes before it.

Try it below. Drag a boundary to give a phase more time. Everything after it slides later. Whatever lands past the end of the round never happens, because the interviewer stops at the bell. The presets reproduce the most common ways the round is lost.

Design time

35 min45 min55 min

Try a plan

RecommendedBoxes firstEstimate everythingSpec writerStrong senior

Design starts at

minute 17

Deep dives start at

minute 31

Planned vs available

45 of 45

Clarify

Estimate

API + data

Design

Scale

Deep dives

Wrap-up

after the bell

Drag a boundary, or focus one and use the arrow keys. Later phases slide with it.

1. Clarify and requirements−
   +
2. Estimates−
   +
3. API and data model−
   +
4. Simplest design, first stages−
   +
5. Scaling stages−
   +
6. Deep dives−
   +
7. Failure and wrap-up−
   +

The Estimate everything preset is the instructive one. Each phase overruns by only a few minutes: 8 of questions, 12 of estimates, 9 of API. Together, they push the deep dives to minute 43, and the failure pass past the bell. So the two places Senior is decided get two minutes between them.

Round length

The 45 minutes above are design time. Real slots differ, and the plan should compress in a known order rather than wherever the time happens to run out.

Slot	Design time	What shrinks
45 minute slot with introductions and questions	35 to 40 min	Requirements to 5, estimates to 3, API and data model to 5, deep dives to 8
45 minutes of design	45 min	The table above
60 minute slot	About 55 min	Nothing: the extra time goes to a third deep dive and a fuller failure pass

Every worked problem ends with a “short on time” line, which says what to skip and what never to skip. They share a pattern. Skip multi-region and secondary features first. Never skip the mechanism the problem exists to test, such as the ticket hold, the ID allocator, or the backwards clock.

Problem shape

The split also depends on where the problem is hard.

Shape	Examples	Shift the time
Scale-driven	News feed, video streaming, top-k, metrics	Estimates up to 5 or 6 minutes: the numbers make the decisions
Correctness-driven	Payment system, stock exchange, Ticketmaster, job scheduler	Estimates down to 3, deep dives up to 13 or 14: the hard part is a race, a failure or a guarantee
Well-known	URL shortener, Pastebin, rate limiter	Move fast through the basics; the interviewer expects depth on code generation, caching or the race

TradeoffA fixed time budget

We gain

Every graded dimension gets evidence before the bell, and you notice early when a phase overruns, while there is still time to compress.

We give up

A budget held too rigidly ignores the interviewer. If they want to spend 15 minutes on the data model, that is where their signal is, and the plan bends. The budget is a default, not a script.

Driving the conversation

The candidate is expected to drive: to decide what comes next and keep the round moving without being prompted. Driving is not talking without pause. It means making the plan visible, checking it at the right moments, and following the interviewer when they steer.

Checkpoints

A checkpoint is a one-sentence summary plus a choice for the interviewer. It belongs at four places: after requirements, after estimates, after the first working design, and before each deep dive. Each takes about 15 seconds.

Style	Sounds like	Result
None	Continuous design, no pauses	The interviewer cannot steer, and may let you spend ten minutes on something they don’t care about
Open question	“Does that look good?”	Usually “sure”, which tells you nothing
Summary plus a choice	“Reads dominate 100 to 1, so the cache comes next. Or would you rather see code generation first?”	A real answer, and the interviewer feels in control of where depth goes

Say this out loud

That’s a working design: every create and redirect works, and it has three problems I’ll fix in order. The read load is the biggest, so I’ll start there unless you’d rather I go somewhere else.

Choosing the deep dives

Who picks	When it fits	Risk
The interviewer	They ask a pointed question, or name a topic	None. Their question is the deep dive. Follow it
You propose the crux, they confirm	The default: you name the two hardest parts and why	Low. If they redirect, you learned where their rubric is
You pick your strongest topic	Never as the only reason	Depth on a part that does not matter reads as avoiding the part that does

The hardest part of the problem is almost always the right first choice. Think of the seat hold in Ticketmaster, fan-out in the news feed, or the backwards clock in the ID generator. A candidate who finds it unprompted shows the problem navigation the interviewer is grading.

TradeoffProposing deep dives instead of waiting

We gain

You show that you know where the problem is hard, which is itself a strong signal. And you choose a topic you can settle with numbers.

We give up

You might pick something the interviewer has no interest in. The confirmation question costs ten seconds and removes that risk.

Following an interruption

An interruption is information. “What about X?” usually means the interviewer wants X now. Or that something you said worried them. Answer it. If it changes the design, change the design. Then return to the plan with one sentence. Hints are not attacks. “Are you sure one database handles that?” means the number does not work. The best response is to recompute, not to defend.

“What if X fails?”

This question comes in almost every round. A strong answer has a fixed shape. Find the component on the drawing. Then give the blast radius, how you detect it, what you do about it, and what users see. End with what the mitigation costs.

Answering a failure question in five parts

Scroll or pinch to zoom, drag to pan

• Color key
• Service

The follow-up is the real test: the interviewer pushes until the mitigation itself is under stress. An answer with no detection step (“we fail over”) or no user impact reads as a guess.

Where candidates lose the round

Most failed rounds fail in one of a small number of ways, and each has an early symptom you can notice yourself.

Failure	What it looks like	The symptom you can catch	The fix
Jumping to boxes	A full architecture in the first five minutes	You are drawing before you know the read to write ratio	Requirements and numbers first; one box per forced need
Buzzword stacking	Kafka, Redis, Cassandra, Kubernetes, each named and none explained	You cannot say which number or requirement forced a component	For each box, name the problem it solves and what it costs
No numbers	“It needs to scale”, “it’ll be a lot of traffic”	Nothing in your design has a trigger	Four estimates, each ending in “so we”
Ignoring failure	The round ends on the happy path	Minute 40 and nothing has died yet	A failure pass over the final drawing, the critical path first
Over-designing	Multi-region, sharding and event sourcing for 40 writes a second	A component whose bottleneck you cannot point at	Stop when the numbers stop
Running out the clock	Thorough requirements and API, deep dives at minute 43	The first design is not up by minute 20	Clock checks at minutes 17 and 31; compress what came before
Defending instead of revising	The interviewer hints at a flaw and the candidate argues	You are explaining why it is fine rather than recomputing	Recompute; if it breaks, change the design and say why

Jumping to boxes is the most common, because it feels productive. The problem is not the boxes themselves. A final design often has most of them. It is that nothing in the round justified them. So the interviewer cannot tell understanding from memory. Worse, the design is fixed before the requirements are known. Say a candidate draws Cassandra in minute three, for a payment system. They have chosen a store without multi-partition transactions, for a ledger that needs them.

Buzzword stacking is the same mistake, with product names. Describe the mechanism first (“an append-only log, partitioned by code, so a consumer can replay after a bug”). Name the product second, if at all.

Common mistake

Memorizing the final diagram

Learning a problem’s final architecture and reproducing it is the fastest way to look strong for five minutes and weak for forty. The interviewer changes one requirement (“links are editable”, “now 100 times the creates”) and a memorized design has no reasoning to adapt with. Study how each stage was forced instead: the numbers, the bottleneck, the fix and its cost. Then a changed requirement is a changed number, and you know which stage it moves.

Go deeperSmaller ways to lose points2 min

Habit	Why it costs	Instead
Asking “what scale should I design for?”	Hands the interviewer your job	Propose a number and ask if it is in range
“It depends” with no follow-through	True and empty	“It depends on X. If X is small, A; here X is large, so B”
Naming a consistency model loosely	“Strongly consistent” for a cache that serves replicas is a red flag	Name the guarantee per operation: read your own write, eventual within a second
Silence while thinking for minutes	The interviewer cannot grade what they cannot hear	Think in short sentences: “I’m deciding between A and B, the question is X”
Writing code no one asked for	Minutes on syntax instead of design	Pseudocode for a mechanism only when it is the point, such as a token bucket
Asking for feedback at the end	Most interviewers are not allowed to give it, and it uses up question time	Ask about the team’s real systems instead

Signals by level

The framework is the same at every level. What changes is how much of it you drive yourself, how deep the deep dives go, and how far beyond the prompt you see. Levels differ between companies, so read this as a rough guide, not a rubric.

Phase	Mid-level	Senior	Staff
Requirements	Lists features and asks about scale	Pins every non-functional with a number and names the hard requirement	Questions the requirement itself (“does this need to be real time, or does hourly meet the business need?”)
Estimates	Correct rates and storage	Separates average from peak and says which numbers do not matter	Adds cost: which line of the bill dominates, and what that rules out
Design	A working design with prompting	Drives from simple to v1 unprompted, each stage forced by a number	Names the one or two decisions that are expensive to reverse, and spends care there
Deep dives	Explains how a component works	Compares options with numbers, picks one, says how it fails	Ties the choice to how the system evolves: migration, the next 10x, what another team must build
Failure	Mentions replication and retries	Per-component blast radius, detection and user impact	Operations: what pages someone, how a deploy or a bad config is rolled back, where the risk sits
Conversation	Answers questions	Drives, checkpoints, follows interruptions	Frames the round: states the plan, the crux and what is deliberately left out, and holds the time

The step from mid to senior is mostly driving and numbers. A senior candidate needs no prompt to move from one phase to the next. And every decision has a quantity behind it.

The step from senior to staff is mostly scope and time. A staff candidate questions whether the problem as stated is the right one. They see the system a year later: migrations, cost, other teams. And they find which decisions deserve the most care, because they are hard to undo. Staff rounds often run 60 minutes with a vaguer prompt, precisely to leave room for this.

None of the staff signals replace the senior ones. A candidate who discusses organizational tradeoffs but cannot settle the locking question with numbers reads as mid-level with good vocabulary.

In the interview

Interviewer asksWe have ten minutes left and you haven't covered failure. What do you do?

Say the plan out loud, and compress: “I’ll spend five minutes on failure of the critical path, then wrap up.” Pick the one component whose failure matters most. Usually that’s the primary store on the write path, or the cache in front of a read-heavy path. Give blast radius, detection, mitigation, and what users see. Then one sentence each on the others (“Kafka down delays analytics, redirects are unaffected”). End with the two or three decisions, and what they gave up. Ten minutes covering every component lightly is worse than five on the one that matters.

Interviewer asksWhy did you add Kafka here?

The question is whether the component was forced or recited. A good answer names the requirement and the number. “Click events arrive at 4,000 a second. The redirect must not wait for analytics. And I want to replay events after an aggregation bug. So I need a durable log, partitioned by code, so one link’s events stay ordered.” Then say what it costs: another system to run, and at-least-once delivery, so duplicates to handle. Maybe the honest answer is that a simpler queue, or an in-process buffer, would do at this scale. Saying so is a strong signal, not a weak one.

Interviewer asksSkip the estimates, I don't care about the numbers. Just design it.

Skip the arithmetic, and keep the decision. State the one number the design depends on as an assumption, in one sentence. “I’ll assume reads outnumber writes about 100 to 1, and the hot set fits in memory, so the read path is cache first.” The interviewer is usually testing whether you can adapt. They’re not inviting a design with no quantities. Later, when a stage needs a trigger, give it as a threshold (“once the table passes about 2 TB”), not a derivation.

Interviewer asksThat design works. Where would you go deeper?

Name the crux and why, then offer a second. “The hardest part is keeping two fans from holding the same seat, when 25,000 attempts a second hit one event. So I’d start with the locking options and the contention math. After that, the case where payment succeeds after the hold expired. Which would you rather see?” The choice of deep dive is itself graded. Picking the part that makes this problem hard shows you understood it.

Common mistake

Treating the framework as a script

The framework is a default order, not a contract. If the interviewer jumps to a deep dive at minute 8, go there. Their question is where the signal is, for them. Come back to the skipped steps only if they matter, in one sentence each (“I’d assumed a single region, which I’ll revisit”). A candidate who says “I’ll get to that after the API” is optimizing for the framework, not the interview.

Mid-level covers

Follows the steps in order, reaches a working design with some prompting, explains each component correctly, and covers failure when asked.

Senior adds

Drives every transition, and pins requirements as numbers. Lets each number force a stage. Proposes deep dives on the crux, and settles them with options and arithmetic. Separates failure by path. Keeps the clock, so deep dives start by about minute 31.

Seen in

Every worked problem follows this framework, so each is a full example. Read them by the step each one shows best:

Step	Where it is done best
Requirements and the hard one	Web crawler (politeness per host shapes the whole frontier), Ride hailing (pings outnumber rides 500 to 1, so that path may lose data), Ad click aggregator (clicks are billed, so a counting error costs money)
Estimates that flip a decision	Pastebin (metadata and bodies in two stores), Typeahead (keystrokes, and an index that fits in RAM), Proximity service (index size decides replicate or shard), Hotel reservation (1,000 searches per booking), Instagram (bytes, not requests), Video streaming (dollars per hour watched), File sync (every estimate ends in a decision)
Sizing the right unit	Leaderboard (the cost of one command on 100 million members), Distributed cache (memory and throughput separately), Key-value store (replica operations, not client ones), Job scheduler (the peak at the top of the hour), Metrics and monitoring (series, not samples)
Small numbers, said small	Payment system (600 payments a second, so all the time goes to correctness), Stock exchange (one engine in memory survives to the final design)
API and the simplest design	Chat (the push channel decides the protocol), Notification system (stage 1 sends inline, wrong in an instructive way)
Stages forced by numbers	URL shortener (the reference: six stages, each with its trigger), News feed (pull for celebrities only where the math pays)
Deep dives settled precisely	Ticketmaster (locking settled with Little’s law), Unique ID generator (the backwards clock and zombie workers), Rate limiter (the counter store down), Collaborative editor (OT or CRDT), Top-k (exact or a sketch, decided by memory), Message queue (what exactly once really means)

Recap

The goal. Produce evidence for four things before the bell: problem navigation, a working design, technical depth, and clear communication. The final diagram is not what gets graded. The reasoning that produced it is.

The nine moves. Requirements, estimates, API, data model, the simplest design, stages forced by numbers, deep dives, failure, wrap-up.

The 45 minutes. About 6 on requirements, 4 on estimates, and 7 on API and data model. Then 8 to a working design, 6 on scaling, 10 on deep dives, and 4 on failure and wrap-up. First design by minute 17. Deep dives by minute 31.

Requirements. Verbs for functional, numbers or named guarantees for non-functional. Propose numbers instead of asking for them. Name the hard requirement.

Estimates. Only the numbers that flip a decision, each ending in “so we”. Shorten them when the numbers are small, and say so.

Design. Start with one service and one database, name its flaws, and add one component per measured bottleneck. Stop when the numbers stop.

Driving. Checkpoints with a summary and a choice. Propose the crux as the first deep dive. Answer failure questions with blast radius, detection, mitigation, user impact and cost.

Losing the round. Jumping to boxes, buzzword stacking, no numbers, ignoring failure, over-designing, and running out the clock before the deep dives.

Levels. Mid reaches a working design. Senior drives it with numbers and goes deep. Staff questions the scope and sees the system a year later.

Further reading

• Back of the envelope estimation and API design on this site. Then the URL shortener, the reference worked problem, read with this page’s steps in mind.
• Service Level Objectives, Google’s Site Reliability Engineering book: how to turn “available” and “fast” into the numbers non-functional requirements need.
• Designing Data-Intensive Applications, Martin Kleppmann: the mechanisms behind most deep dives, from replication and partitioning to transactions and consistency.
• Alex Xu, System Design Interview: An Insider’s Guide (2020). Its chapter on a framework for system design interviews describes a similar four-step structure, in a shorter form.