0% completed
Importance of Discussing Trade-offs
On This Page
What a Trade-off Is
A Sentence You Can Reuse
Three Worked Examples
Four Ways to Lose Points
When the Interviewer Asks "Why Not the Other One?"
How This Chapter Is Organized
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 made a decision. That difference is what this chapter is about.
What a Trade-off Is
A trade-off is what you give up in order to get something else.
It is not a drawback you failed to avoid, and it is not a mistake to apologize for. If one option were better in every way, there would be no decision to make. Nobody would ask you about it. A design question is interesting exactly because 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 two things. Do you know what your choice costs? And did you pick 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 during the interview. This pattern gives you one:
I'll use X. That gives us A. It costs us B. I'm accepting B because of requirement 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 requirement shows you are designing this system, not reciting a comparison table. Naming the alternative shows you considered one.
Three Worked Examples
Choosing a database. "I'll use a key-value store for the session data. All lookups are by session id, so reads take single-digit milliseconds, and the data splits across machines easily. It costs us the ability to query sessions by anything except the id. I'm accepting that because no requirement asks for other queries. If we later need 'all active sessions in this region', I'd add a relational store or a separate index."
Choosing how services communicate. "The order service will publish an event, and the email service will consume it, instead of a direct call. A slow or failed email service then cannot fail an order. It costs us a short window where the order exists and the email has not been sent. I'm accepting that because a late email is fine and a lost order is not. If the caller needed the result before answering 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, and this workload is about 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 send a user's own reads to the primary right after they write, so everyone sees their own changes."
None of these takes longer than a few sentences, and none needs unusual knowledge. They are ordinary decisions stated completely.
Four Ways to Lose Points
Naming a technology without its cost. "I'll use Kafka" is not a decision. The interviewer cannot tell whether you chose it or only recognized it. Say what it gives you and what it costs.
Comparing without deciding. A balanced comparison that ends without a choice looks like avoiding the decision. Interviewers grade judgment, and you cannot show judgment without committing. Pick one, say why, and move on.
Re-deciding a settled question. If the requirements already say the system must stay available during a regional outage, the consistency question is answered. Do not spend three minutes weighing it again. Say that the requirement settles it, and continue. Time spent on settled questions is taken from the open ones.
Conceding a cost nobody challenged. Some candidates repeat every weakness of their design until they abandon a reasonable choice. State the cost once, calmly, then keep the decision. Raising a concern once shows confidence. Repeating it shows doubt.
When the Interviewer Asks "Why Not the Other One?"
The most common mistake here is to assume you were wrong and switch.
Usually the interviewer is testing whether you know why you chose. Sometimes they are adding new information. You can tell the difference by checking one thing: did a requirement change?
If no requirement changed, keep your choice. Explain the reasoning again, starting from the requirement that drove it. If a requirement did change, say so and update the design: "This now has to work across regions, so the trade-off changes. I'd accept eventual consistency here." Changing your mind for a stated reason is a strength. Changing it only because you were questioned is not.
How This Chapter Is Organized
The rest of the chapter covers the trade-offs that appear most often. They are grouped by where in a system the decision is made, the same way the System Design Master Template is grouped. Read the chapter in order to prepare generally, or go straight to the group you need.
Foundations. The two measurements every design is judged against, and the basic scaling choice: Latency vs Throughput and Horizontal vs Vertical Scaling.
How the request reaches you. Decisions made at the edge, before your code runs: Proxy vs Reverse Proxy, CDN Usage vs Direct Server Serving, and Load Balancer vs API Gateway. Then API Gateway vs Direct Service Exposure and Token Bucket vs Leaky Bucket.
Where the work happens. How the services are shaped: Stateful vs Stateless Architecture and Serverless vs Traditional Server-based. And how they communicate: REST vs RPC, Synchronous vs Asynchronous Communication, and Push vs Pull Architecture. Finally, 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, and ACID vs BASE. Then 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 sits, 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.
Start with Latency vs Throughput, because it gives you the vocabulary the rest of the chapter is written in.
💡 In the interview: you do not need to discuss every trade-off, and trying to do so will cost time you need elsewhere. Give the most detail to the two or three decisions that shape the architecture. Those are 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 it in a fixed shape: choice, gain, cost, the requirement that makes the cost acceptable, and the alternative if that requirement changed. Tie each decision to a requirement, commit to it, and do not re-open what the question already settled.
Reading Progress
0%
On This Page
What a Trade-off Is
A Sentence You Can Reuse
Three Worked Examples
Four Ways to Lose Points
When the Interviewer Asks "Why Not the Other One?"
How This Chapter Is Organized