0% completed
Importance of Discussing Trade-offs
On This Page
What a Trade-off Actually Is
A Sentence You Can Reuse
Three Worked Examples
Four Ways Candidates Lose Points Here
"Why Not the Other One?" Is a Probe, Not a Rejection
How This Chapter Is Organised
Two candidates reach the same point in a design and say almost the same thing.
The first says: "I'll put a cache in front of the database."
The second says: "I'll put a cache in front of the database. That takes most reads off the database and cuts read latency. It costs us a window where a user can see stale data. I'm accepting that because the requirement says the feed can be a few seconds behind. If this were account balances, I would not."
Both named the same component. Only one of them designed anything. That difference is what this chapter is about.
What a Trade-off Actually Is
A trade-off is what you give up in order to get something else.
That is worth stating plainly, because it is not the same as a drawback you failed to avoid, and it is not a risk you should apologise for. If an option were better in every way, there would be no decision to make and nobody would ask you about it. The reason a question is interesting is that every answer costs something.
So when an interviewer asks you to justify a choice, they are not looking for the perfect component. They are checking whether you know what your choice costs, and whether you picked it on purpose.
A Sentence You Can Reuse
Most candidates know the trade-offs. What they lack is a habit for saying them out loud under pressure. This pattern gives you one:
I'll use X. That gives us A. It costs us B. I'm accepting B because of R. If R changed, I'd use Y instead.
Five parts: the choice, the gain, the cost, the reason, and the alternative.
The last two matter most. Anyone can list a pro and a con. Tying the decision to a specific requirement shows you are designing for this system rather than reciting a comparison table. Naming the alternative shows you actually considered one.
Three Worked Examples
Choosing a database. "I'll use a key-value store for the session data. Lookups are all by session id, so I get single-digit millisecond reads and it shards easily as we grow. It costs us the ability to query sessions by anything other than the id. I'm accepting that because nothing in the requirements asks for that. If we later need to answer questions like 'all active sessions in this region', I'd move this to a relational store or add a separate index."
Choosing how services communicate. "The order service will publish an event and let the email service consume it, rather than calling it directly. That means a slow or failed email service cannot fail the order. It costs us immediate consistency, so for a short window the order exists and the confirmation email has not been sent. I'm accepting that because a delayed email is fine and a lost order is not. If the caller needed the result before responding to the user, I'd make it a direct call."
Choosing a replication setup. "Writes go to a primary and reads go to replicas. That scales reads, which is what this workload needs since it is roughly ninety percent reads. It costs us replication lag, so a user can write something and not see it on the next read. I'm accepting that in general, but I'd route a user's own reads to the primary right after they write, so they always see their own changes."
Notice that none of these are longer than a few sentences, and none of them require unusual knowledge. They are ordinary decisions stated completely.
Four Ways Candidates Lose Points Here
Naming a technology without naming its cost. "I'll use Kafka" is not a decision, it is a noun. The interviewer cannot tell whether you chose it or just recognised it. Say what it gives you and what it costs to run.
Listing both sides and never deciding. A fair, balanced comparison that ends without a choice suggests you are avoiding the decision. Interviewers are evaluating judgment, and you cannot show judgment without committing. Pick one, say why, and move on.
Inventing a trade-off the requirements already settled. If the question already told you the system must stay available during a regional outage, do not spend three minutes weighing consistency against availability. Note that the requirement settles it and keep going. Time spent re-deciding what is already decided is time you do not have for the parts that are open.
Conceding a trade-off nobody challenged. Some candidates volunteer every weakness of their design unprompted, and end up abandoning a reasonable choice. State the cost once, calmly, then stay with the decision. Raising a concern shows confidence. Repeating it shows doubt.
"Why Not the Other One?" Is a Probe, Not a Rejection
When an interviewer challenges a choice, the most common mistake is to assume you were wrong and switch.
Usually they are testing whether you know why you chose it. Sometimes they are giving you new information. You can tell the difference by listening for whether they changed a requirement.
If the requirements have not changed, keep your choice and explain the reasoning again in terms of the constraint that drove it. If they have changed, say so out loud and change the design to match: "If we now need this to work across regions, then the trade-off changes and I'd move to eventual consistency here." Changing your mind for a stated reason is a strength. Changing it because someone frowned is not.
How This Chapter Is Organised
The rest of the chapter works through the trade-offs that come up most often. They are grouped the way the System Design Master Template is grouped, by where in a system the decision gets made. Read it in order if you are preparing generally, or go straight to a group if you are stuck on one decision.
Foundations. The two measurements everything else is judged against, and the basic scaling axis: Latency vs Throughput and Horizontal vs Vertical Scaling.
How the request reaches you. The decisions made at the edge, before any of your code runs: Proxy vs. Reverse Proxy, CDN Usage vs Direct Server Serving, Load Balancer vs. API Gateway, API Gateway vs Direct Service Exposure and Token Bucket vs Leaky Bucket.
Where the work happens. How the services are shaped, and how they communicate with each other and with the client: Stateful vs Stateless Architecture, Serverless vs Traditional Server-based, REST vs RPC, Synchronous vs Asynchronous Communication, Push vs Pull Architecture, Polling vs. Long-Polling vs. WebSockets vs. Webhooks and Batch Processing vs Stream Processing.
Where the data is stored. The group that usually decides whether a design works at the stated scale: SQL vs. NoSQL, Normalization vs Denormalization, ACID vs BASE Properties in Databases, Strong vs Eventual Consistency, Primary-Replica vs Peer-to-Peer Replication and Read Heavy vs Write Heavy System.
How you make it fast. Where a cache is placed, and how it behaves once it is there: Server-Side Caching vs Client-Side Caching and Cache-Aside vs Read-Through, Write-Through vs Write-Back.
💡 In the interview: you do not need to discuss every trade-off, and trying to do so will cost you time you need elsewhere. Give the most detail to the two or three decisions that shape the architecture, usually the data store, the consistency model, and how services communicate. For everything else, one clause is enough: "load balancer here, standard round robin, nothing interesting about it."
Key takeaway: a trade-off is what you give up to get something else, and every real design decision has one. State them in a fixed shape: the choice, what it gains, what it costs, the requirement that makes the cost acceptable, and what you would pick instead if that requirement changed. Tie the decision to a requirement, commit to it, and do not re-open what the question already settled.
Start with Latency vs Throughput, which gives you the vocabulary the rest of the chapter is written in.
On This Page
What a Trade-off Actually Is
A Sentence You Can Reuse
Three Worked Examples
Four Ways Candidates Lose Points Here
"Why Not the Other One?" Is a Probe, Not a Rejection
How This Chapter Is Organised