The Trade-off Cheat Sheet
System design has no right answers, only defended ones. Every recurring decision, what you gain, what you pay, and the sentence that makes it sound deliberate.
Covers: Every major decision as an explicit trade, the sentences that justify each one, and the follow-up you will get
Interviewers are not checking whether you picked the option they would have picked. They are checking whether you knew there was a choice. This lesson is a reference: every recurring decision, the two sides, and the sentence that frames it as a judgement rather than a default.
30-second answer
Every recurring decision reduces to spending one resource to buy another. Consistency buys correctness with latency and availability. Caching buys latency with staleness and invalidation complexity. Denormalisation buys read speed with write cost and drift risk. Asynchrony buys responsiveness with eventual consistency and ordering complexity. Microservices buy team autonomy with availability, latency and operational cost. The skill is naming both sides and tying the choice to a stated requirement.
Storage and consistency
| Decision | Gain | Cost | Choose the second when |
|---|---|---|---|
| Strong vs eventual consistency | Correctness, simple reasoning | Latency, reduced availability under partition | Staleness is invisible to users - likes, feeds, counters |
| Normalised vs denormalised | One source of truth, cheap writes | Join cost on every read | A measured hot read path dominates and the data changes slowly |
| SQL vs NoSQL | Ad-hoc queries, transactions, constraints | Harder horizontal write scaling | Access patterns are known and fixed, and write volume exceeds one primary |
| Replicate vs shard | Read scale, availability, simple | Does not help write volume or data size | A single primary can no longer take the writes or hold the data |
| Sync vs async replication | Zero data loss on failover | Write latency; slowest replica gates you | Losing a few seconds of writes is acceptable |
Performance
| Decision | Gain | Cost | Choose the second when |
|---|---|---|---|
| Cache vs always fresh | 10–100× latency, less origin load | Staleness, invalidation, cold-start risk | Correctness at read time is non-negotiable |
| Precompute vs compute on read | Fast reads | Write amplification, stale results | The result space is too large or too personalised to precompute |
| Sync vs async processing | Simple, immediate result | User waits for slow work | The user need not see the result immediately |
| Batch vs stream | Throughput, simplicity, cheap | Latency measured in minutes or hours | Decisions must be made within seconds |
| Push vs pull | Fresh, event-driven, low read cost | Write amplification, breaks on fan-out skew | The producer has enormous fan-out - the celebrity case |
Architecture and operations
| Decision | Gain | Cost | Choose the second when |
|---|---|---|---|
| Monolith vs microservices | Simplicity, transactions, one deploy | Teams block each other at scale | Independent teams genuinely need independent deploys |
| Stateful vs stateless services | Locality, fewer lookups | Hard to scale, deploy and fail over | Only when state is inherent, as with WebSocket connections |
| Build vs buy | Control, no vendor lock-in | Engineering time forever | It is not your core differentiator |
| Single vs multi-region | Simple, cheap, consistent | Latency for distant users; no region-failure survival | Global latency or data residency is an actual requirement |
| Fail open vs fail closed | Availability under dependency failure | Possibly serving wrong or unauthorised results | The dependency is a security or correctness control |
Three phrases that reliably score
- “It depends on X, and here's how.” - then actually resolve it using the requirement. Saying 'it depends' and stopping is the worst possible answer; saying it and then deciding is the best.
- “I'd start simple and add this when we hit Y.” - shows you scale in response to evidence rather than anxiety.
- “The failure mode of this choice is Z, and here's how I'd detect it.” - pairs a decision with its monitoring, which almost nobody does unprompted.
Say these points
- Every decision spends one resource to buy another - name both sides.
- Tie the choice to a stated requirement, not to a preference.
- Complexity is a finite budget; declining to add something is a real decision.
- 'It depends' must always be followed by 'and here's how I'd resolve it'.
- Pair each choice with its failure mode and how you would detect it.
Avoid these mistakes
- Presenting a choice as obvious when it is contested.
- Saying 'it depends' without resolving it.
- Optimising for a scale the requirements never mentioned.
- Never mentioning what you deliberately chose not to build.
Expect these follow-ups
- Give me a case where you would choose eventual consistency for money.
- When would you deliberately keep a stateful service?
- What is the most over-used component in system design interviews?
Showing 1 of 1 questions for system-design-tradeoffs-cheatsheet.
Check your understanding
3 questions · no sign-up, nothing stored