How to talk about trade-offs in a system design interview

A strong system design answer does not avoid trade-offs; it prices them. For each decision, say what it buys, what it costs in a number or a named failure, why that cost is acceptable for this system, and what would make you change your mind. Interviewers hear “it depends” all day. What they rarely hear is “it costs this much, and here is why we can afford it.”

Why “it depends” is not an answer

Almost every design question has more than one defensible answer. A cache can hold data for ten seconds or ten minutes. A queue can drop the oldest work or refuse new work. A write can wait for one replica or three. None of these is right in general, which is why “it depends” sounds wise and says nothing.

The useful part is what it depends on. A candidate who says “a ten-minute cache is fine because a price shown ten minutes late costs us at most a refund on a handful of orders, and the database cannot take the read load without it” has made a decision. A candidate who says “we could cache it, but there are consistency trade-offs” has only noticed that decisions exist.

The four parts of a priced trade-off

Use the same four parts every time, out loud:

1. The choice. One option, stated plainly. “Product prices are cached for ten minutes.”
2. What it buys. Tie it to a requirement you were given. “It keeps the database under its read limit at peak, which is five times normal traffic.”
3. What it costs. A number or a named failure, not a category. “A price change takes up to ten minutes to show. During a sale, some customers see the old price at checkout.”
4. When you would change it. The condition that flips the decision. “If price errors become a legal problem, we invalidate the cache on every price write instead, and pay for the extra write path.”

The third part is the one most answers skip. “Consistency” and “latency” are categories. “Up to ten minutes of old prices” is a cost someone can accept or refuse.

A trade-off is not the same as an error

There is no single correct design, but there are wrong ones. The difference matters, because interviewers grade them differently.

• A priced trade-off is a defensible choice whose cost you stated. Two strong candidates can make opposite choices here and both pass.
• An unpriced trade-off is a defensible choice whose cost you never mentioned. It usually reads as luck rather than judgment.
• An error breaks a stated requirement, whatever it buys. If the brief says “no order may be charged twice” and your retry design can charge twice, that is not a trade-off between simplicity and correctness. It fails the brief.

Before you defend a choice as a trade-off, check it against the requirements you were given. If it breaks one, change it; don’t price it.

Find the cost by running the worst hour

The fastest way to find what a decision costs is to run it against the worst realistic moment for the system: the traffic peak, the dependency outage, the deploy that goes wrong. Ask three questions:

• What happens to requests during that hour with this choice?
• Who notices first: a user, an alert, or nobody?
• How long until it is fixed, and what has to happen for that fix to reach the affected users?

The last question catches a common mistake. A fix that needs a schema migration does not help during the incident. A setting that only takes effect on restart does not help the processes that are already running. Price the system as it is deployed on the day, not as it will be after the fix ships.

Say what you are not optimizing

Good answers also name the costs they chose not to pay. “We are not building multi-region writes; a regional outage means the service is read-only for up to an hour, and the business accepted that for the first year.” This tells the interviewer you saw the option and declined it on purpose.

A short example

Brief: an internal reporting dashboard reads from a production database that is already near its CPU limit at month end.

• Choice: serve the dashboard from a read replica.
• Buys: month-end report queries no longer compete with customer writes on the primary.
• Costs: replica lag. At month end the replica can fall a few minutes behind, so a report run right after a large import may miss the newest rows. Finance needs to know that.
• Would change if: finance needs reports that include every row up to the second, for example for a regulatory close. Then we run those specific reports on the primary, off-peak, with a query timeout.

That is the whole skill: one choice, its cost in plain terms, and the condition that changes it.

Common questions

Is there a correct answer to a system design interview question?

Usually there are several defensible designs and some wrong ones. A design is defensible when each decision meets the stated requirements and you can say what it costs. It is wrong when it breaks a requirement, such as charging a customer twice or losing data the brief said must be kept.

How many trade-offs should I discuss?

Price the two or three decisions that carry the most risk for this system, in depth, rather than listing every possible option. Interviewers prefer three priced decisions to ten named ones.

What if I don’t know the exact cost?

Estimate it and show the estimate. “At 2,000 requests a second and a 1% failure rate, that is about 20 failed requests a second during the outage” is better than no number, and the interviewer can correct an assumption you made visible.

How do I practice this?

Take a design you know, pick its riskiest decision, and write the four parts for it: the choice, what it buys, what it costs, and when you would change it. Then run it against the system’s worst hour and check whether the cost you wrote is the cost you would actually pay.