Tradeoff thinking
Nobody is grading your architecture. They are grading whether you knew what you were giving up, and said so.
The thing that is actually being scored
Twenty-three 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.
| Axis | Buying more of this… | …costs you this | The sentence |
|---|---|---|---|
| Consistency vs availability | Every reader sees the latest write | Writes must fail or block during a partition; higher write latency | "During a partition I'd rather reject the write than serve a stale balance — this is a money path." |
| Latency vs throughput | Fast individual responses | Less batching, less pipelining, worse hardware utilisation, higher cost per request | "Batching to 50 ms windows triples throughput and adds 50 ms of latency — for an analytics write path that's free, for a chat send it isn't." |
| Cost vs performance | Headroom, replicas, more cache, more regions | Money, linearly, forever — plus the opportunity cost of the team maintaining it | "A second region roughly doubles infra spend to move availability from three nines to four. Is that worth it for this product?" |
| Complexity vs capability | A feature the simple design can't do | A new failure mode, a new backup story, a new upgrade path, a new page at 3am | "That's a fourth stateful system. Each one is an on-call runbook — I'd want the capability to be worth that." |
| Read-optimised vs write-optimised | Cheap reads: denormalisation, materialised views, fan-out on write, more indexes | Expensive, amplified writes; stale derived data; harder invalidation | "Read:write here is 100:1, so I'll pay on write. If it were 1:1 I'd compute at read time instead." |
| Build vs buy | Control, exact fit, no per-GB bill | Team time forever, and you are now the on-call for a commodity | "I'd buy the CDN and the queue and build the matching engine — that's the only part that's our differentiator." |
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.
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.
| Empty | Complete |
|---|---|
| "It depends on the use case." | "It depends on whether users read their own writes. If they do, I'll route reads to the primary for that user for a few seconds after a write. If they don't, replicas are fine and I save the primary's capacity." |
| "SQL or NoSQL, it depends." | "It depends on whether the access pattern is known and stable. It is — everything is a lookup by conversation id — so I'll take a wide-column store and give up ad-hoc queries. If analysts need ad-hoc access I'd ship a copy to a warehouse rather than compromise the serving store." |
| "Depends how much scale we need." | "At 100 writes/sec one Postgres primary handles this with an order of magnitude of headroom. I'd revisit above about 5,000 writes/sec, which at current growth is roughly three years out." |
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.
| Actual scale | What is genuinely sufficient | What candidates reach for anyway |
|---|---|---|
| 10k DAU, ~10 writes/sec | One Postgres box, one app tier, daily backups. Genuinely. Nothing else. | Microservices, Kafka, Redis, Elasticsearch, Kubernetes |
| 1M DAU, ~500 writes/sec, 20k reads/sec | Postgres primary + 2 replicas, Redis cache, CDN for static, one background worker | Sharding, a service mesh, event sourcing, CQRS |
| 50M DAU, 20k writes/sec | Now sharding, a real queue, a separate read model, multi-AZ. The complexity has been earned. | Multi-region active-active before anyone asked for four nines |
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. Nobody in the history of these interviews has been downgraded for correcting themselves cleanly.
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.