How to Run a System Design Interview, and a Design Review

Stagefront is an event ticketing service that exists only in this course, where a stadium show goes on sale at exactly ten in the morning and two hundred thousand people press the same button inside a minute. On Tuesday 15 September 2026 it gave a candidate forty five minutes and asked them to design a ticket seller.

Which is to say it asked them to design the thing it already runs, and marked the answer against its own history.

The candidate did well. They asked what a seat was, asked whether an oversold seat was recoverable, and when they were told it is a lawsuit they stopped drawing and said the seat claim has to commit in one transaction on one machine, which is exactly what lesson 015 settled for this company. They named idempotency keys for the payment call, which lesson 019 owns. They drew a cache in front of the seat map and when asked what happens if it restarts mid-sale, they said the holds cannot live there, which is lesson 007's answer in lesson 007's own words. Everybody in the debrief wrote down the same phrase. Strong fundamentals.

They started on Monday 21 September.

On Thursday, day four, they put a proposal in the engineering channel. One database takes every write in the only minute that matters, which is true and published: lesson 003 put a single ticket database on the purchase path, lesson 006 counted the twenty application boxes that carry the on-sale minute, and lesson 010 pointed out that ordinary pools on them put five hundred connections against a database that can usefully run a few dozen at a time. The proposal was to shard the seat table by event, so each show lands on its own machine.

It is the correct textbook move and it is wrong here, and the reason is one sentence long. Lesson 013 has it: sharding spreads load across data, and does nothing about load concentrated in time on one key. Shard Stagefront by event and the on-sale minute is one machine at a hundred percent CPU with fifteen idle machines watching the show it is not selling.

Somebody said that in the channel in about twenty minutes. And then the interesting part. The new engineer asked where that was written down at Stagefront, and the answer was nowhere, because the seat table had never been cut and nobody had ever needed to say why not. Every on-sale the company had ever run, forty a year by lesson 003's count, had run on a design decision that was never taken.

So they wrote it down, in a file they created that afternoon, because they were the only person in the building who had just learned it.

What forty five minutes can see

An interview has no history. Nothing the candidate says can be checked against a running system, because there isn't one, so every answer is a prediction and the room contains nobody who can falsify it.

That rules out most of what people think they are measuring. You are not assessing the design: forty five minutes of talking produces an artefact nobody can build, including the candidate. You are not assessing whether it would survive, because surviving takes years and this takes until lunch. And lesson 002 already named the thing you are probably measuring instead, in a sentence about a different room: the engineers who seem to reason quickly in a design review are usually just people who have the latency table memorised. Point that at an interview and it stops being an observation and becomes a scoring bug. Vocabulary arrives fast, sounds like judgment, and is the cheapest half of this skill to acquire.

Here is what is left, and I think it is the only thing.

An interview can observe whether a number the candidate produced changed a choice they made later. That is it. It cannot be recalled, because the number came from inputs you chose. It cannot be performed, because it has to show up thirty minutes afterwards in a different part of the design. And it is the whole skill, because a design that does not move when the numbers move is not a design, it is a diagram.

Run it on Stagefront and watch where the division goes. Two hundred thousand people in a minute is lesson 017's 3,333 requests a second. Call the stadium forty thousand seats, which 017 took from lesson 009. A purchase path that converts lesson 004's five hundred payment calls a second empties it in eighty seconds.

Now subtract. A hundred and sixty thousand of those people were never getting a ticket.

That subtraction takes four seconds and it decides what system you are designing. A candidate who does not do it designs a faster purchase path, because every mechanism they know is on that side: a queue, a pool, a shard, a lock. A candidate who does it designs for the refusal, and lesson 021 priced why. A limiter at five hundred a second refuses 2,833 a second, and once you add lesson 020's phone app trying three times and the person behind it trying until they believe the answer, a hundred and sixty thousand disappointed people over eighty seconds is six thousand refusals a second. At three attempts each that is twelve refusals for every seat sold, which is my division of 021's two figures rather than a number 021 prints. Lesson 021's rule is that a limiter is sized by the traffic it refuses rather than the traffic it admits, and it calls that the most consistently missed thing about them.

So the dominant workload in a ticket seller is saying no. It is not a trick question and it is not a trivia question either, because the two numbers that produce it are the first two numbers anybody states about the problem.

The practical shape of this is small and most interviewers get it backwards, me included for a long time. Give the candidate both numbers in the first five minutes, unprompted, with units. Then stop talking. The signal is whether they divide, and you cannot see it if you are filling the silence with hints, and you definitely cannot see it if you are waiting for a mechanism you have in mind to be named.

Then ask the three questions this course has earned that need no history at all. Lesson 030 asks what measurement would make you buy the next box, and nothing about it needs a system to exist. Lesson 055 asks for a maximum with its derivation on the same line, and its move is the sharp one: find the first thing the tier multiplies that it does not own, which at Stagefront is a connection count and at Galewatch, which collects a reading every two seconds from each turbine on the wind farms it monitors, was a connection count as well, while the partition count everybody had checked turned out never to be the ceiling. Lesson 056 asks which lines are rent, which are meters, and which are somebody's afternoon.

None of those three can be answered from vocabulary. All three can be answered about a design drawn twenty minutes ago.

And two questions to stop asking, because both destroy the one thing you can see. How would you scale this has no wrong answer, so it measures nothing but fluency. Worse is naming the mechanism yourself: ask whether they would put a queue in front of the purchase path and you have converted a design decision into a yes, and the candidate will say yes, because you asked. If a mechanism matters, give them the number that implies it and wait. Lesson 017's waiting room is the one Stagefront has never built, and a candidate who reaches it from the hundred and sixty thousand rather than from the word queue has told you something a whole afternoon of interviews usually does not.

What I cannot tell you how to test is whether somebody will ask the day-four question. That is the thing Stagefront actually needed from that hire, it is worth more than the design, and I know no way to see it in forty five minutes. The closest proxy I trust at all is whether the candidate asks what you already decided and why, rather than asking for requirements. It is a weak signal and I would not weight it heavily.

The other room

A design review is the same vocabulary and the opposite problem. It has nothing but history. The system is running, the numbers are real, and the people who made every decision in it are sitting in the room, which is the part that changes everything.

In an interview nobody is defending anything. In a review everybody is.

That single difference invalidates the most natural question in the language. Ask "why did you choose Postgres here" and you will get a defence, assembled on the spot, from whatever reasons are available now rather than the ones that were available then. It will be coherent. It will usually be a reconstruction. Lesson 060 found at Marlow Books, the four-person online bookshop in this course, that five of the ten mechanisms it runs arrived sideways. Three of those five: a lock that exists because a crontab got copied onto a second machine, a circuit breaker that is an outlier detection setting on a twenty dollar balancer that nobody there has ever called a breaker, and an object store bought because a 500 GB volume filled at ten to four in the morning. Ask the founder why the payout job takes a lock and he will have an answer. The answer will be better than the history.

So ask lesson 030's question instead, which is the same question pointed the other way. What measurement would change this? Nobody has to defend a measurement. It is answerable, it is checkable, and when the answer is "nothing would change it" you have found either a load-bearing decision or a thing nobody has thought about since it shipped, and the next three minutes tell you which.

Then there is the question of what a review spends its hour on, and this course has been complaining about that in passing for sixty lessons without naming the pattern.

Lesson 056 said a design review at Marlow held in July would have spent its hour on the fleet, because the fleet is $1,520 of a $1,598 monthly bill, ninety five percent, and it is the line nobody is allowed to change. Lesson 057 said a design review would have argued about which of Galewatch's permissions can read, because a read is what a breach looks like in the news, while the dullest line in the file was may write a reading, and that is the line that fabricated thirteen and a half hours of weather. Lesson 059 put the number on that night: 7,290,000 readings no turbine made. Lesson 014 said the shard key fixes three things and reviews skip the third, which is the smallest thing you can ever move. Lesson 005 put it as a complaint about documents: capacity is what gets written down, and availability is what actually signs it off.

Different topics, one shape. A review argues about the biggest number and the scariest word, and the decisions are in neither. The biggest number is usually fixed by something outside the meeting, and the scariest word is scary because of how it reads in a newspaper rather than because of what it does to your system. Lesson 014's third thing and lesson 005's signature are the same complaint one step back: the hour goes to whatever is easiest to say out loud, and the decision is sitting under whatever nobody had a word for.

Which gives you an agenda, and an agenda is most of what a review is. Take it from lesson 030's copy table: for every fact the system depends on, how many copies exist and how long two copies may disagree. The rows worth the hour are the ones with nothing in the last column. Marlow's checkout switch had that row open from September, and lesson 060 finally measured it at thirty seven seconds, during which the shop confirmed an order its founder believed was impossible. Then add lesson 056's third shape, the lines that are somebody's afternoon, because those are the only lines in the whole system that an hour of six people's attention can actually move.

One move on the logistics, and it is the one I would fight for. The author does not present. Somebody else walks the design, out loud, with the author in the room and quiet until they are wrong. A design a second person cannot walk has not been communicated yet, which is worth knowing in the first ten minutes rather than in the first incident, and it puts the author in the only posture where they are not defending: correcting. Lesson 060's thirty seven seconds are the kind of thing this finds, because the person walking it would have asked how the two files get written and discovered that the answer is twice, by hand.

Six questions, sorted by what they can see

The course has earned six good questions by now, and they do not all work in both rooms. Sorting them is more useful than collecting them, and the axis is sharper than it looks.

An interview is scored on what the candidate had to compute. A review is scored on what you can check.

That is the same property from two sides. In an interview, an answer that could have been guessed or recalled tells you nothing, because there is no system to catch a bluff. In a review, an answer about intent tells you nothing, because the author is defending and the system is right there to be opened instead.

Spoken, since the audio skips tables: the first three work in both rooms, because the candidate has to do arithmetic and the reviewer has something to open. Lesson 050's question, which is whether a second region was bought to win the on-sale lottery or to survive an ordinary Tuesday, is guessable in an interview and checkable in a review, because the two purchases want different runbooks and the runbook either exists or does not. Lesson 054's flag removal date is the same: a candidate can say two weeks and mean nothing, and a reviewer can open the commit that introduced the flag and find out.

Then the last row, which is the one worth the lesson. Lesson 060's question is the most important thing a review can ask and the only one with nothing to check it against. There is no file of refusals. Git holds what you built. The diagram holds what you bought. A runbook holds what you operate. Nothing anywhere in a normal software company records a decision not to do something, which is why lesson 060's warning is that the refusals are the half of an architecture a new engineer will undo.

The practice that is meant to fix this has a name you will meet at work, the architecture decision record: a short file per decision, with the context, the choice made, and the alternatives rejected. It is a good practice and I would keep it. It also misses the exact case that cost Stagefront a day, because a file gets written when somebody argues, and nobody ever argued about the seat table. There was one table, there had always been one table, and a decision that was never taken has no record to write. The rejected alternatives are also the thinnest section of nearly every one of those files I have read, and they are the only section a new engineer needs.

Lesson 059 belongs beside it and arrives from the other direction. Its question is who would be able to tell, and its finding is that you cannot make a record unchangeable, only make a change detectable. Point that at a design review and the answer is uncomfortable: a refusal is the one decision in your system that leaves no trace at all, so nobody can tell it ever happened.

The refusal has no file

Day four at Stagefront is what that looks like from inside. Nothing was lost, because nothing had ever been written. The design was right, for a reason nobody had said out loud, and a new engineer spent half a day on a proposal that every on-sale in the company's history had already answered.

Twenty minutes of somebody's time, which is cheap. The part that is not cheap is that it will happen again, with a different mechanism, because the channel is not a file.

So here is the output a design review should produce, and it is not a verdict. A verdict is what a meeting produces. A review's product is one entry per refusal, with the measurement that would reverse it. Stagefront's, written on day four:

We do not shard the seat table.
By seat: one purchase of four adjacent seats spans up to four
  machines, so no transaction, and an oversold seat is a lawsuit.
By event: the on-sale minute is one machine at 100% with the
  rest idle, because the load is concentrated in time.
Reverses if: two shows go on sale in the same minute, or one
  show's writes saturate the database before the seats are gone.

Two rejected cuts and two reversing measurements. Note that the second measurement is a number nobody has. Lesson 010's connection arithmetic is the only database figure this company owns in these lessons, so the review has turned a refusal into something somebody could go and measure. That is lesson 030's rule arriving where it is most useful: the architecture is the ordered list of measurements, and a refusal with no measurement beside it is a belief.

Lesson 060 found the other half of this and it is the better half. A refusal done properly ends at a cheap substitute rather than at no, and the substitute is the thing nobody builds. Lesson 048 refused a configuration service for Marlow and left one command and two health-endpoint fields behind. Lesson 042 refused a payment breaker and left behind ship the fallback and rehearse it by hand. Lesson 053 refused encrypting the covers and left behind spend the attention on the credential that can write to that bucket. Every one of those substitutes is sitting unbuilt, and lesson 060 explained why: they are afternoons, and an afternoon has no price, so it never reaches the part of the week where things get approved.

Which means the entry goes in during the review, in the room, while somebody is still saying it. Not in a follow-up. Lesson 060's last finding is that the fix that ships is the one your hands are already on, and the only hands on a refusal are the ones in the meeting it was explained in.

Now the uncomfortable arithmetic, because this is a lesson about events that cost people's time. Marlow refused fourteen mechanisms across Phase 2 and lesson 060 priced every one. Fourteen entries at a minute each is fourteen minutes, once, for a shop whose entire architecture fits on one side of A4. A bigger company's list is longer, and still shorter than one sprint. The cost is not the writing.

The cost is that somebody has to be in a state of not knowing, and the only people reliably in that state are the ones who just arrived.

A new engineer's first three weeks are the only design review your architecture will ever get from somebody with no stake in it. They will ask why the seat table is one table, why there are two files, why a breaker nobody calls a breaker is doing the work of one. Each of those questions is a refusal looking for a file. Then, somewhere around the third week, they learn the answers, stop asking, and join the set of people for whom none of it needs saying. Lesson 060 asked you how you would work out which of a system's mechanisms are load bearing when nothing records why any of them is there. Today's half is who else is in the room while you do it, and the answer is that you have about three weeks, which is my own count rather than anybody's research, before they are no use to you, through no fault of theirs.

Hire for the questions. Then run the review before the questions run out.

Recap

An interview has no history and a review has nothing else. Everything else about the two events follows. In an interview nothing can be checked, so an answer is worth what it cost the candidate to produce. In a review everything can be checked, and the author is defending, so an answer about intent is worth less than a thing you can open.

An interview can observe one property: whether a number the candidate produced changed a choice they made later. Give them both numbers in the first five minutes and then be quiet. At Stagefront the number is a subtraction, two hundred thousand people against forty thousand seats, and it decides whether they design the sale or the refusal, which lesson 021 sized at six thousand refusals a second against five hundred admissions. Vocabulary arrives fast and sounds like judgment, which is lesson 002's complaint about a different room.

Do not ask why. Ask what would change it. Why invites a defence and gets a reconstruction, because half of what a small system runs is load bearing by accident and the founder will still have a reason. Lesson 030's question is answerable without anybody losing face, and "nothing would change it" is itself a finding.

A review argues about the biggest number and the scariest word, and the decisions are in neither. Marlow's hour would go on ninety five percent of the bill that nobody may change, and lesson 057's would go on reads while a write fabricated the data. Set the agenda from lesson 030's copy table instead: the rows with no limit in the last column, plus lesson 056's afternoons, which are the only lines an hour of attention can move.

A review's product is one entry per refusal, with the measurement that would reverse it. Git holds what you built, the diagram holds what you bought, and nothing holds what you refused, which is why a new engineer will propose it again on day four. Write the entry in the room, because an afternoon never gets approved later. And a refusal with no reversing measurement beside it is a belief.

A new engineer's first three weeks are the only design review you will get from somebody with no stake in the answer. They are the only people in the building who do not know, and they stop being that in about three weeks.

Check your understanding

1. You have forty five minutes with a candidate and a whiteboard. Write the two numbers you would state in the first five minutes for the system you work on, say what division you are hoping they do, and say what the design should look different about if they do it.

2. A candidate names a mechanism per minute for twenty minutes and never computes anything. Another computes one ratio, gets it wrong by a factor of ten, and redesigns around their own wrong answer. Say which you would advance and what one further question you would ask the one you are unsure about.

3. Lesson 060 asked you what cheap substitute your team's last three refusals left behind. Take one of those refusals now and write its entry instead: what you do not do, the reason, and the measurement that would reverse it. Then say whether that measurement exists today.

4. You are reviewing a design whose author built it and is in the room. The one thing you are worried about is a cache with no stated expiry. Write the three questions you would ask in order, and say which of them you would drop if the author gets defensive at the first.

5. Galewatch's engineers want a design review of the ingestion path and have booked an hour with six people. Say what you would put on the agenda, which of this course's Galewatch numbers you would open first, and what you would refuse to spend the hour on even though somebody will want to.

6. Somebody joined your team three weeks ago and has stopped asking questions. Say what you would do this week to recover what they noticed and did not raise, and why the same move will not work in month three.

7. Your company asks candidates to design the product it already sells. Argue both sides, and say what you would change about the scoring if you kept the question.

Next lesson

062 Design a URL Shortener. The questions are in place, so the designs start, beginning with the smallest system in this course that still has to answer every one of them.