System-design interviews feel endless because the surface
problems are endless — feeds, chats, shorteners, ride-hailing, streaming. But
underneath, the same small set of trade-offs keeps reappearing. Learn to
recognise them and you can reason about a system you have never designed,
because you are no longer solving a novel puzzle — you are choosing sides on
familiar tensions. Here are the seven that come up again and again.
1. Consistency vs availability
The most famous trade-off, and for good reason. When a
system is distributed and the network inevitably fails, you must choose: keep
serving requests with possibly-stale data (availability), or refuse to answer
rather than risk being wrong (consistency). A banking ledger leans one way; a
social feed leans the other. The interview signal is not knowing the CAP
theorem by name — it is deciding which your system should favour and
explaining why.
2. Latency vs throughput
Fast for one request, or efficient across millions?
Batching, queuing, and buffering all raise total throughput while adding
latency to any individual operation. A real-time trading path optimises
latency; an analytics pipeline optimises throughput. Strong candidates state
which one the problem actually cares about instead of vaguely wanting both.
3. Strong vs eventual consistency
A more granular cousin of the first trade-off, and one
interviewers love to probe. Strong consistency means every read sees the latest
write — simple to reason about, expensive to scale. Eventual consistency lets
replicas converge over time — cheap and highly available, but it forces you to
handle temporarily stale or conflicting data. Knowing where each is acceptable
(a "like" count can be eventual; an account balance usually cannot)
is exactly the judgment being tested.
4. SQL vs NoSQL
Not a religious war, a trade-off. Relational databases give
you strong consistency, joins, and transactions, at the cost of harder
horizontal scaling. Non-relational stores give you flexible schemas and scale,
at the cost of pushing consistency and relationships into your application. The
mature answer names the access patterns first and picks the store that serves
them — and often uses both.
5. Read-optimised vs write-optimised
Every storage decision quietly answers this. Indexes,
caches, and denormalisation make reads fast and writes more expensive;
write-heavy systems may invert that entirely. The first question a senior
engineer asks about a new system is "what's the read-to-write ratio?"
— because it dictates half the design. Much of the craft here comes from the distributed-systems foundations that
explain why these access patterns behave the way they do at scale.
6. Normalisation vs denormalisation
Store each fact once and join when you need it (clean,
consistent, slower to read), or duplicate data so reads are fast (quick, but
now you must keep copies in sync). This is the concrete lever behind
"read-optimised vs write-optimised," and interviewers use it to see
whether you understand that every performance gain is bought with a maintenance
cost somewhere else.
7. Simplicity vs scalability
The most underrated trade-off, and the one that separates
real judgment from pattern-matching. Every scaling technique — sharding,
caching, queues, microservices — adds moving parts, failure modes, and
operational burden. The best answer to "how would you scale this?" is
often "I wouldn't, yet" — building the simplest thing that meets the
stated requirements and knowing exactly where you'd add complexity when the
numbers demand it. Over-engineering a design in an interview signals the same
poor judgment it would on the job.
How to actually use these
The trap is treating these as vocabulary to recite. Their
value is as a lens. When you get a prompt, walk through the list: what
does this system need — consistency or availability? How does its read-to-write
ratio shape storage? Where is simplicity worth protecting? Suddenly a blank
problem has structure, because you are interrogating it with questions that
always apply.
The fastest way to internalise the lens is to watch it
operate on real systems. Working through worked
system-design case studies with these seven trade-offs in mind turns
them from abstract tensions into instincts you reach for automatically.
The bottom line
You will never memorise enough system designs to cover what
an interviewer might ask. You do not need to. Almost every question reduces to
these seven trade-offs, and an engineer who can identify which ones a problem
hinges on — and choose a defensible side — is doing exactly what the interview
is built to measure.
