The Follow-Up Question Is the Interview

There is a moment about fifteen minutes into a system design interview when the candidate finishes the last arrow, steps back, and says "so that's the high-level design". Some of them relax slightly here. They have delivered the thing they practiced.

Then the interviewer says: "Great. Now the cache goes away. Talk me through the next minute."

Everything before that sentence was the setup. The grading happens after it, and the split in preparation time is almost exactly backwards — enormous effort spent rehearsing an opening that will be over in a quarter of an hour, almost none spent on the thirty minutes that decide the outcome.

The good news is that the follow-ups are not infinite. They run along five axes, and you can pre-load all five for any design in about ten minutes of thought.

Failure

"What happens when this component dies?" — asked about whichever box you were least likely to have considered.

The trap is that candidates prepare for the database failing and not for the boring things: service discovery being unreachable, the cache being empty rather than absent, a dependency that is slow rather than down. Slow is the hard case, and it is the one interviewers reach for, because a dead dependency fails fast and a slow one holds your threads until the whole tier is unavailable.

Pre-load it by walking your own diagram and, for each box, finishing this sentence: when this is unavailable, callers see ___, and when it is slow, callers see ___. If those two answers are the same, you are missing a timeout somewhere.

Scale

"Now it's ten times the traffic."

The weak answer is "add more servers", which is true of the stateless tier and irrelevant to everything else. The question is not how to grow, it is what breaks first, and the honest answer is usually not the thing you scaled.

Pre-load it by finding your design's ceiling before anyone asks. Every design has exactly one component that saturates first, and naming it unprompted is one of the strongest moves available to you: "the bottleneck here is the write leader — everything else scales horizontally, so at ten times the volume this is where it hurts and here's what I'd do about it." Then have the second bottleneck ready too, because a good interviewer will remove the first one and ask again.

Correctness under concurrency

"Two requests arrive at the same instant. What happens?"

This axis catches candidates who designed the happy path in a distributed system and reasoned about it as though it were a single process. The retry that duplicates a payment. The two clients that both read the counter as 41. The consumer that receives the same message twice because the broker guarantees at-least-once and the network ate an acknowledgement.

Pre-load it by naming, for each write in your design, whether it is idempotent, and if not, what makes it safe — a natural key, a conditional update, a unique constraint doing the real work. "Every write here carries a client-supplied idempotency key, so a retry is a no-op" is a sentence that closes a whole line of questioning.

Operations

"How do you deploy this? How do you roll back? How would you migrate the existing data?"

This is the axis that separates candidates who have run something from candidates who have only designed something, and it is the least practiced of the five by a wide margin. A design that cannot be changed safely is not finished, and interviewers at senior level know it.

The concrete versions worth having ready: how a schema change lands without downtime (add, backfill, dual-write, switch reads, drop — and why that order). What a rollback does to data written by the new version. Whether your service can run two versions at once, because during any deploy it will. What you would put on a dashboard to know the deploy is going badly, and the specific number that would make you stop.

Cost

"This works. Can we afford it?"

The rarest of the five in practice, and the most disarming, because the reflex is to treat resources as free. You do not need a price list — you need to know which line dominates, and it is almost never the compute. Cross-region data transfer, egress to end users, and keeping everything hot in memory when most of it is cold are the usual suspects, and being able to say "the expensive part of this design is X, and here's the cheaper version if we need it" reads as ownership.

Pre-loading, concretely

Take any design you have practiced and answer these before you next open a drawing tool.

1. Which component saturates first, and which one is second.
2. For each dependency: the behaviour when it is down, and the behaviour when it is merely slow.
3. Every non-idempotent write, and what makes retrying it safe.
4. How a schema change ships without downtime, and what rollback does to the data.
5. The line item that dominates the cost.

Five answers, ten minutes, and they transfer between problems far better than the designs themselves do. The bottleneck reasoning you develop for a feed service is the same reasoning for a booking service; the deploy story barely changes at all.

Rehearse in the second half

The reason the first ten minutes are over-prepared is that they are the pleasant part — the design comes out clean, and it feels like progress. The follow-ups are where you find out your design does not survive contact, which is unpleasant and is exactly the point.

So change what you practice. Finish the diagram fast, deliberately faster than you would in the real thing, and spend the remaining time interrogating it: pull a component out, multiply the traffic, fire two requests at the same row, ship a schema change. If you can run the design under load and watch which queue grows, better still — a bottleneck you have seen appear is a bottleneck you will name without hesitating.

The first ten minutes get you the right to be asked the next thirty. Prepare accordingly.