System Design Trade-Offs: How to Answer Like an L6 Instead of an L4
Consistency vs availability. SQL vs NoSQL. Monolith vs microservices. 10 trade-offs with the L4 answer and the L6 answer side by side, so you know exactly what to aim for.
What This Guide Covers
10 trade-offs that appear in every system design interview, with what each level is expected to say
For each trade-off: what it means, when to choose each side, the wrong answer that gets you downleveled, and the answer that gets you promoted
Concrete examples from real systems (not abstract theory)
A scoring framework: how interviewers use trade-off reasoning to calibrate your level
The system design interview is not a knowledge test. It is a trade-off reasoning test.
The interviewer already knows the architecture for the system they are asking you to design.
What they do not know is how you think when there is no single correct answer.
Every meaningful design decision involves giving something up to get something else. SQL gives you consistency but limits horizontal scaling.
Caching gives you speed but introduces staleness.
Microservices give you independent deployment but add operational complexity.
The candidate who says “I would use microservices” without naming what they sacrifice earns an L4.
The candidate who says “I would use microservices because independent deployment matters more than operational simplicity at our team size, and I am willing to pay the cost of distributed tracing and eventual consistency between services” earns an L6.
This guide covers 10 trade-offs that appear in virtually every system design interview. For each one, I explain what it means, when each side wins, and the specific phrasing that separates an L4 answer from an L6 answer.
How Interviewers Use Trade-Offs to Calibrate Level
Before the trade-offs, understand the scoring model.
Interviewers mentally place your answer on a spectrum.
L4 answer: Names a technology or approach. “I would use Redis for caching.” No trade-off discussed. No alternative considered. The interviewer learns that you know Redis exists but not whether you understand when it is the wrong choice.
L5 answer: Names the trade-off.
“I would use Redis for caching because we are read-heavy. The trade-off is cache invalidation complexity, but TTL-based expiration is sufficient for this use case because serving slightly stale feed data is acceptable.”
The interviewer learns that you understand both sides.
L6 answer: Names the trade-off, quantifies it, and connects it to requirements.
“I would cache the last 100 messages per channel in Redis with a 60-second TTL. At our 70,000 read QPS, this reduces database load by 90%. The trade-off is that messages edited in the last 60 seconds may appear unedited to some users. Given that message edits represent less than 1% of operations, this staleness window is acceptable. If we needed stronger consistency, I would switch to event-based invalidation, which adds complexity to the write path but eliminates the staleness window entirely.”
The interviewer learns that you reason about trade-offs the way a production engineer does.
The pattern is clear: each level adds a layer of depth.
L4 names the choice.
L5 names the trade-off.
L6 quantifies the trade-off and connects it to the specific system’s requirements.
The 10 trade-offs below give you practice at all three levels.
Trade-Off 1: Consistency vs Availability
When a network partition occurs (and they always do in distributed systems), your system must choose.
A consistent system refuses to serve requests that might return stale data. It returns an error instead.
An available system always serves a response, even if the data might be outdated.
When consistency wins: Financial systems. If a user’s bank balance is $100 and they attempt a $100 withdrawal from two ATMs simultaneously, the system must not allow both. Serving stale data (showing $100 at both ATMs after one withdrawal already succeeded) leads to real monetary loss. Returning an error (”temporarily unavailable, try again”) is better than serving wrong data.
When availability wins: Social media feeds. If a user’s feed shows a post from 3 seconds ago instead of a post from 1 second ago, nobody notices. But if the feed returns an error page, the user leaves. Uptime matters more than perfect freshness.
The L4 answer: “I would use eventual consistency because it scales better.”
The L6 answer:
“For the messaging core, I use strong consistency: messages within a channel must appear in order and must not be lost. I achieve this with synchronous replication to one replica before acknowledging the write. For the unread count feature, I use eventual consistency: the badge might be off by 1 for a few seconds, and that is acceptable because recalculating unread counts on every message would add 50ms to the write path for no user-visible benefit.”
Why the L6 answer is better: It applies different consistency models to different parts of the same system, based on what each part actually needs. The 10 ways candidates misuse the CAP theorem covers the specific misconceptions that lead to weak answers on this trade-off.
Trade-Off 2: Latency vs Throughput
Latency is how long one request takes.
Throughput is how many requests the system handles per second.
Optimizing for one often hurts the other.
When latency wins: User-facing APIs. A search result that takes 2 seconds feels broken. Users will leave. You optimize for the lowest possible response time, even if it means the system handles fewer total requests per second (by doing less work per request, serving from cache, returning approximate results).
Keep reading with a 7-day free trial
Subscribe to System Design Nuggets to keep reading this post and get 7 days of free access to the full post archives.