How to explain trade-offs in a system design interview
A trade-off answer has four parts: the options, the requirement that decides between them, your choice, and what the choice costs. Said in one or two sentences, it shows the interviewer that you chose on purpose. Naming options without choosing, or choosing without a reason tied to the requirements, are the two ways candidates lose this signal.
Key points
- Options, deciding requirement, choice, cost: four parts, one or two sentences.
- Tie every choice to a requirement you wrote down earlier, ideally one with a number.
- Say the cost of your choice before the interviewer does.
- Say what would make you change your mind: that is the strongest version of a trade-off.
- When challenged, restate the requirement and either defend the choice or update it. Both are fine.
The four-part sentence
Every design decision can be said in the same shape. It sounds rehearsed the first few times and natural after a week of practice.
- Options: “We could do A or B.”
- The deciding requirement: “The thing that matters here is X,” where X is a requirement you already stated.
- The choice: “So I’ll pick A.”
- The cost and the trigger to revisit: “That costs us Y. If Z changed, I’d move to B.”
“For the feed I could compute it when the user opens the app, or precompute it when a post is written.”
“The requirement that decides it is the 200 millisecond read budget, with reads a hundred times more common than writes.”
“So I’ll precompute on write for most accounts. The cost is heavy fan-out for accounts with millions of followers, so for those I’d merge their posts in at read time instead.”
Six trade-offs that come up again and again
The table lists what each side buys and what it costs, and the requirement that usually decides. Learn the deciding requirement rather than a winner: the same pair goes either way in different problems.
| Trade-off | Side A buys | Side B buys | Usually decided by |
|---|---|---|---|
| Relational vs key-value store | Joins, transactions, flexible queries | Simple horizontal scale, predictable latency per key | Access patterns and whether you need multi-row transactions |
| Strong vs eventual consistency | Every read sees the latest write | Lower latency and availability during network splits | What a stale read costs the user (money, safety, or only a slightly old count) |
| Cache-aside vs write-through cache | Only hot data cached; simple writes | Cache always warm for written keys | Read-to-write ratio and how bad a stale or cold read is |
| Push vs pull (fan-out on write vs read) | Fast reads | Cheap writes, no wasted work for inactive users | Read/write ratio and the follower distribution |
| Synchronous call vs queue | Simple flow, immediate result | Absorbs spikes, isolates failures, allows retries | Whether the caller needs the result now |
| At-least-once vs at-most-once delivery | Nothing lost, but duplicates possible | No duplicates, but messages can be lost | Which is worse for this message; at-least-once plus idempotent handling is the common answer |
Put a number on the deciding requirement
“Reads are much more common” is weak. “About 50,000 reads and 500 writes a second, so a 100 to 1 ratio” is strong, because the interviewer can check the logic. You do not need exact figures; you need figures that are in the right order of magnitude and that you derived out loud a few minutes earlier.
A worked case: a leaderboard for a mobile game with 2 million daily players, each finishing about 10 games a day. That is 20 million score writes a day, around 230 a second on average and perhaps 2,000 at the evening peak. Players open the leaderboard about 5 times a day: 10 million reads, around 115 a second. Here writes outnumber reads, which flips the usual intuition. A sorted set in an in-memory store handles both at this scale; the trade-off to discuss is durability, because an in-memory store that loses a few seconds of scores on a crash may or may not be acceptable. Ask.
When the interviewer pushes back
A challenge such as “why not just use a queue here?” is usually a probe. The interviewer wants to see whether you can reason from the requirements under pressure. Restate the requirement, compare the two options against it, and either keep your choice with the reason or change it and say what changed your mind.
Changing your mind is not a failure when it follows a new fact. Digging in without a reason, or switching every time you are asked, both read badly.
“A queue would absorb spikes, yes. Here the caller needs the result in the same request to show the price, so I’d keep it synchronous and protect the service with a timeout and a cached fallback.”
“That’s a good point: if the price can be a few seconds stale, the cache covers it and the queue becomes reasonable. With that, I’d switch.”
Common mistakes
- Listing three options and moving on without choosing one.
- Choosing by habit (“I always use a NoSQL store”) with no link to this problem.
- Saying “it depends” and stopping there. Say what it depends on, then decide.
- Hiding the cost of the choice, so the interviewer has to dig it out.
- Naming a technology instead of a property: the interviewer wants “ordered writes per key”, not a product name.
- Treating every challenge as a correction and abandoning a sound choice.
Questions
Do I need to know specific databases?
Know the properties behind them: how data is partitioned, what consistency you get, what a write costs. You can name a product, but expect a follow-up on how it actually behaves in your design.
How many trade-offs should I discuss?
Every non-obvious decision deserves one sentence. Two or three deserve the full four-part treatment, usually in the deep dives.
Is it bad to say I am not sure?
No. Say what you are unsure about and reason from first principles. Guides written by interviewers recommend saying so over guessing with confidence.
Practise this out loud with Vera
Mockich’s system design round runs 45 to 50 min on one design, on a shared whiteboard that Vera reads while you talk: requirements, a high-level design, a deep dive into the riskiest part, then twists in load or failure, and a wrap-up. Vera gives at most two small nudges. The report scores requirements and scoping, structure and driving, api and data model, architecture, depth, trade-offs, scale and failure handling, communication (plus operability and cost, scope and influence at lead) and quotes your reasoning.
Related guides
Sources
We read these sources on 2026-11-03; most of the trade-off pairs follow sections of the System Design Primer (CC BY 4.0), and the sentence pattern, the feed and leaderboard examples and their numbers are our own.
- [1] interviewing.io, A Senior Engineer’s Guide to the System Design Interview
- [2] Donne Martin, The System Design Primer: consistency and availability patterns (CC BY 4.0)
- [3] Binh Nguyen, The Patterns of Scalable, Reliable, and Performant Large-Scale Systems (MIT)
- [4] Hello Interview, Delivery Framework (System Design in a Hurry)
- [5] Design Gurus, Scripts for Navigating Tough System Design Questions