Tradeoff thinking

The thing that is actually being scored

The earlier chapters of this topic have been about mechanisms. This one is about the only skill that is graded directly. Interviewers at this level are not comparing your diagram against a reference answer — for most prompts there isn't one, and the interviewer has seen a dozen different designs pass. What they are assessing is narrower and more human: can this person make a decision under incomplete information, explain the cost, and change their mind for a reason rather than for social pressure? That is the job. The system design interview is a forty-five-minute simulation of a design review you will be running for the rest of your career.

Which is why two candidates can draw an almost identical diagram and receive opposite ratings. One says "and then we add Kafka." The other says "I'll add a queue here because the write path is 600k/sec at peak and the consumer can fall behind without hurting the user — the cost is that the feed is now eventually consistent by a few seconds, and I'd revisit if product tells me the write must be read-your-own-write." Same box on the whiteboard. Entirely different signal.

The six axes, and the sentence for each

Almost every decision in system design is one of six tradeoffs wearing a costume. Learning to name the axis out loud is most of the skill — it converts a technology choice into a reasoned position, and it lets the interviewer engage with the reasoning instead of the brand name.

A seventh worth keeping in your pocket: flexibility vs optimisation. Every performance win — denormalisation, a chosen shard key, a precomputed index, a cached projection — is a bet on a specific access pattern. If the product pivots, the optimisation becomes the migration. Saying "this shard key assumes we always query by user, and if we later need query-by-region that's a full reshard" is the kind of foresight that reads as staff-level.

Two more pieces of vocabulary make the price tag concrete. Reliability has a currency: the SLO and its error budget. A 99.9% monthly target leaves about 43 minutes of allowed unavailability; a risky launch, a migration or a deploy freeze is a decision about how that budget gets spent, and each extra nine costs more than the last, so the question is whether the revenue it protects justifies it. And price decisions by reversibility: a feature flag, a cache or an index is cheap to be wrong about, while a shard key, a public API field or a choice of primary datastore is a one-way door that deserves the arithmetic. Include how you would roll the change back, and how you would find out within minutes that it was wrong.

The four-beat move that makes a decision defensible

There is a repeatable structure for any decision you announce, and it takes about fifteen seconds. Assumption, choice, cost, trigger. Beats one and two are what most candidates give. Beats three and four are the entire difference in rating.

Notice the shape: one assumption, one choice, two costs, two triggers. It is four sentences and it is unfalsifiable in the good way — the interviewer can now attack the assumption ("what if it's 10:1?") which is exactly the conversation you want, because you have already told them what you'd do.

"It depends" is only half a sentence

"It depends" is true of every question in this interview, which is precisely why saying it alone scores zero. It is not wrong, it is empty — it transfers the work back to the interviewer. The fix is mechanical: the phrase must always be completed with on what, and then with what you would do in each branch.

The same discipline applies to any comparative you use. "Faster" — than what, by how much? "More scalable" — along which dimension? "More reliable" — measured how? Vague comparatives are the verbal signature of someone reciting rather than reasoning, and experienced interviewers hear them instantly.

Over-engineering is the most common senior-level failure

Mid-level candidates under-design. Senior candidates over-design, and it is the more expensive mistake because it looks like effort. The reflex is understandable: the interview rewards knowledge, knowledge feels like components, so more components must be a better answer. It is not. Every additional stateful system is a permanent operational tax — its own failure modes, its own backup and restore story, its own version upgrades, its own runbook, its own capacity model, its own page at 3am. You do not get to count only the benefit.

The counterintuitive part: proposing the simple thing is a higher-risk, higher-reward move, and that is exactly why it scores. Anyone can list components. Saying "at this scale a single Postgres box is genuinely fine, and here is the number that tells me so, and here is the threshold where I'd change" requires you to have done the arithmetic and to be willing to be wrong in public. That is what the rating is measuring.

How to disagree with your interviewer well

At some point the interviewer will push back, and often they will be deliberately wrong to see what you do. Both failure modes are common. Folding instantly — "oh, sure, we can do that" — reads as never having had a reason for your original choice. Digging in — repeating your position louder — reads as someone who will be difficult in a design review. The scored behaviour is neither.

The move has three parts. Restate their point in your own words, so they know you actually heard it and so you find out whether you understood it. Locate the disagreement on an axis — you are almost never disagreeing about facts, you are weighting a tradeoff differently or working from a different assumption. Then either update explicitly and say why, or hold with a cost.

That last question is the highest-value four words available to you. Pushback usually encodes information the interviewer has and you don't — they know the growth curve because they picked the problem. Asking which assumption to design against converts an argument into a requirements clarification, which is a thing you get points for.

And when you are genuinely wrong, be conspicuous about it: "You're right, I had the read-write ratio backwards — that changes my answer, let me redo it." Visibly updating on evidence is a positive signal, not a recovery from a negative one. Correcting yourself cleanly is a positive signal in a design review, not a mark against you.

Dry run: the four-beat move, then pushback, on one concrete decision

Scenario: 5M DAU, 5 push notifications/user/day. Should the fan-out run on Kafka or a jobs table?

Nothing in row 7 contradicts row 2 — the jobs table was the right call given what beat 1 assumed, and beat 4 already named exactly the condition that would reverse it. The revision is the four-beat move working as designed, not a mistake being corrected.

What separates a senior/staff performance from a mid-level one

• Drives the clock. Mid-level waits to be asked what's next. Senior says "I've got requirements and estimates, I'll spend ten minutes on the core data path, then come back to failure handling" — and then does that, watching the time.
• Commits, then qualifies. Mid-level lists three databases and asks which one you want. Senior picks one in a sentence, says what it costs, and moves on. The pick can be wrong; the refusal to pick cannot be recovered from.
• Numbers precede boxes. Mid-level draws the architecture and adds capacity math if prompted. Senior estimates first and lets the numbers force the components — so every box on the board has an arithmetic reason to exist.
• Names the axis, not just the option. "This is a consistency-versus-availability call and I'm taking availability because it's a like counter" beats any amount of correct-but-unexplained choice.
• Volunteers the weakness. Mid-level defends the design. Senior says "the fragile part here is the cross-shard transaction on checkout — if I had more time that's where I'd focus" before being asked. Interviewers have a mental list of your design's flaws; naming them first turns each one from a discovered gap into demonstrated judgement.
• Simplifies on purpose, with a threshold. "One Postgres box, and here's the number at which I'd shard" is a strictly stronger answer than a distributed store nobody needed. Under-engineering with a stated trigger is judgement; over-engineering is anxiety.
• Talks about operating it. Deploys, migrations, backfills, rollback, on-call load, what the dashboard shows, what pages a human. Mid-level designs a system that gets built. Senior designs one that gets run for five years.
• Handles pushback as information. Restates the objection, locates the disagreement in an assumption, updates or holds with a reason — and asks which assumption to design against rather than guessing.
• Scopes to the ask. Recognises that "design a URL shortener for an internal tool" and "design one for 100 M links a day" are different problems, and refuses to answer the second when asked the first.