How to Explain Trade-offs in a System Design Interview
To explain a trade-off in a system design interview, name the options, the requirement that decides between them, what your choice costs, and when you would switch. One sentence carries it: "I'm choosing X over Y because of requirement Z; it costs us W, and if V changes I'd revisit it." Say it about real decisions in your own design, three or four times in the hour.
What interviewers mean by trade-offs
Every design decision gives something up. A cache makes reads fast and introduces stale data. A queue absorbs spikes and adds delay. Denormalizing speeds up a query and makes writes harder. When an interviewer asks about trade-offs, they are not asking for a list of pros and cons. They want to see that you know what your design is bad at, that you chose that weakness on purpose, and that you can say when the choice would stop being right.
Amazon's preparation page for SDE II candidates lists the objectives a design is judged against: practicality, accuracy, efficiency, reliability, optimization and scalability. They pull against each other, and the interesting part of any design is where you let one of them give way to another. On Devana's system design rubric, trade-offs are one of the four communication metrics, 25 of the 100 points.
Meta's guide to its systems design interview says it directly: "A good solution compares and contrasts different approaches. It explores the tradeoffs present in any complex engineering problem and it makes intelligent, reasoned decisions about those tradeoffs."
Our minute-by-minute guide to the system design interview ends on one sentence worth rehearsing: "Here is the trade-off I am making, here is what it costs, and here is when I would revisit it." This article takes that sentence apart and puts it to work.
The four-part trade-off sentence
- The options. Name at least two real alternatives. A trade-off with one option is just a decision.
- The deciding requirement. Tie the choice to something from the scoping: the read rate, the latency target, the consistency requirement. This is what turns an opinion into an argument.
- The cost. Say plainly what you give up. "This means a follower may see a celebrity's post a few seconds later than a friend's."
- The trigger to revisit. Say what would change your mind: a different ratio, a stricter requirement, a growth threshold. It shows the decision is conditional, which it is.
The second part is the one most candidates skip, and it is the one that matters most. "I'd use NoSQL because it scales" names an option and a vague benefit. "I'd use a key-value store because every read is by key and we never join, and we need to spread fifty terabytes across machines" names the requirement that decided it.
Six trade-offs, worked
These come up in most designs. Each uses the four parts, and each links to a worked design on our problems pages where it appears in context.
Fan-out on write or on read (a news feed)
"I'll push new posts into followers' feeds for normal accounts, because feed reads outnumber posts by a wide margin and reads must load in under a second. That makes a post from a huge account expensive, so for accounts above a follower threshold I'll pull their posts at read time instead. The cost is a little extra work on every read for users who follow those accounts. If celebrity posting became much more frequent, I'd revisit the threshold."
A counter or a hash for short keys (a URL shortener)
"I'll generate keys from a counter, handed out to servers in ranges, rather than hashing the URL, because it guarantees uniqueness without a collision check on every insert. The cost is that keys are sequential and guessable. If guessability mattered, for example for private links, I'd permute the id before encoding it."
Synchronous or queued delivery (webhooks)
"Deliveries go through a queue per endpoint rather than being sent inline when the event happens, because one merchant's slow endpoint must not hold up anyone else. The cost is delay and at-least-once delivery, so merchants will see duplicates and need the event id to deduplicate. If a merchant needed strict ordering, I'd talk about what it costs them in throughput."
Strong or eventual consistency (a flash sale)
"The stock count has to be exact, because overselling by even one unit is unacceptable, so reservations go through a single atomic check-and-decrement. The product page's stock badge can be eventually consistent, since a few seconds' lag there costs nothing. The cost of the strict part is that it is a hot spot, so I'll split the stock across a few counters if one cannot keep up."
Cache with a TTL or with invalidation
"I'll cache profile reads with a five-minute expiry rather than invalidating on every write, because profiles change rarely and the read rate is high. The cost is that an edited profile can look stale for up to five minutes. For the owner viewing their own profile, I'll read through to the database so they always see their change."
A relational database or a key-value store
"Orders go in a relational database, because we need transactions across the order and its items and queries by customer and date. The cost is that scaling writes means sharding by customer later. Click events go in a wide-column store instead, because they are append-only, enormous and only ever read by key and time."
Make the trade-off concrete with numbers
A trade-off lands harder when it is tied to the estimate you made at the start. "Reads dominate" is a claim. "A hundred thousand redirects a second against a few hundred new links a second" is a reason. If you estimated the load in the first ten minutes, which you should, reuse those numbers when you justify each choice: they are why the estimate is worth doing.
The same goes for the cost. "Some staleness" is vague; "up to five minutes for other viewers, never for the owner" is a specification the interviewer can accept or push on.
When the interviewer pushes back
Pushback is usually a probe, not a verdict. The interviewer wants to see whether you can hold a reasoned position, update it when given a new fact, and tell the two apart. Three moves work:
- Acknowledge the point. "That's right, the queue adds latency."
- Re-check it against the requirement. "The requirement was delivery within a minute, and the queue adds seconds, so I think it still holds."
- Change your mind with a reason, if the reason is new. "If we need ordering per merchant, then a single partition per merchant makes sense, and I'll accept the lower throughput."
What does not work: defending the choice by repeating it, or abandoning it the moment it is questioned. The first reads as stubborn and the second as unsure. Both suggest the choice was not reasoned in the first place.
Example phrases
- "There are two reasonable options here: ... and ..."
- "Given that reads outnumber writes about a hundred to one, I'll ..."
- "The cost of that is ..., which I think is acceptable because ..."
- "Where this design is weakest is ..."
- "If the requirement were ... instead, I'd switch to ..."
- "I'm optimizing for ... at the expense of ..."
- "Let me check that against the latency target we agreed on."
Mistakes that weaken a trade-off
- Listing pros and cons without choosing. The interviewer asked you to design something; a survey is not a design.
- "It depends" without saying on what. "It depends on the read to write ratio, and ours is read-heavy, so ..." is a good answer. "It depends" alone is not.
- Claiming a choice has no downside. Every choice has one. If you cannot name it, the interviewer will, and that is worse.
- Saving trade-offs for the last five minutes. Make them at the moment of each decision, then summarize at the end.
- Technology names instead of consequences. "Kafka" is not a trade-off. "A durable log, so consumers can replay after an outage, at the cost of running it" is.
The same habit applies in coding rounds, on a smaller scale: time against space, a simpler solution against a faster one, readability against cleverness. Say it the same way: options, requirement, cost.
Practicing it
Pick a design from the problems pages and, before reading the worked answer, write down three decisions you would make and the four-part sentence for each. Then say them aloud. The system design building blocks cover the options you will be choosing between. To practice under questioning, Devana's system design mock interviews give you a whiteboard the interviewer can read and follow-up questions about your actual design.
Related in this series: the clarifying questions that set up your trade-offs, what to say when a follow-up goes past what you know, and how interviewers score communication.
Frequently asked questions
How many trade-offs should I discuss in a system design interview?
Three or four real ones, each at the moment you make the decision, then a short summary at the end. The ones worth stating are where a reasonable engineer could have chosen differently.
Is "it depends" a good answer in a system design interview?
Only if you say what it depends on and then decide. For example: it depends on the read to write ratio, and ours is read-heavy, so I will cache. On its own, "it depends" avoids the decision the interviewer asked for.
What if I choose the wrong option?
There is rarely a single right option. Interviewers look for a choice tied to a stated requirement, an honest cost and a condition for revisiting it. If they push back with a new fact, changing your mind with a reason is a good outcome, not a failure.
Do trade-offs matter in coding interviews too?
Yes, on a smaller scale: time against memory, a simpler solution against a faster one, readability against cleverness. State them the same way: the options, the requirement that decides, and the cost.
More Articles
System Design Interviews: A Minute-by-Minute Guide to the Hour
August 6, 2026 · 13 min read
Clarifying Questions to Ask in Coding and System Design Interviews
October 19, 2026 · 8 min read
What to Say When You Don't Know the Answer in a Technical Interview
October 19, 2026 · 8 min read