System Design Trade-offs: How to Justify Any Design Choice (Eventual Consistency, Caching)Lesson 05: Trade-offs and How to Justify a Design
Roadmap
You are in System Design Interview Prep, Track 01, Core Fundamentals: lesson 5 of 19 (how to justify any design choice). It builds on Lesson 04: Non-Functional Requirements. Next comes Lesson 06: Vertical Scaling.
These are the written notes for the lesson's video. Prefer paper? The same notes are a free, printable PDF: download SD-A-005.pdf.
Concept
Every design choice improves one quality and costs another; a senior answer names the choice, the reason from the requirements, what you accept, and how you limit it.
Explanation
There is no free lunch
The same tensions come up in almost every design. Knowing them by name lets you spot them early and talk about them clearly.
Figure 1. Three trade-offs you will meet in nearly every interview. The requirements decide where the dot sits.
A worked example
Product page and a cache. A product page reads from the database on every request, and the database is struggling. You add a cache with a 60-second expiry. Database load drops by ~80%. The price: a user might see a price up to a minute old.
Now say it out loud with a four-part template:
Figure 2. The four-part trade-off statement. Part 3 is what interviewers listen for: you know what you gave up.
“We chose a cache over more read replicas, because the requirement is fast reads at low cost. We accept prices up to 60 seconds stale, and we bypass the cache at checkout, where the price must be exact.”
From “it depends” to a decision
“It depends” is a fine start but not an answer. Say what it depends on, then commit:
- List the quality attributes that matter (latency, consistency, cost …).
- Rank them using the requirements.
- Score each option against them.
- Pick, and state what would change your mind.
| Option | Read latency | Freshness | Cost | Verdict |
|---|---|---|---|---|
| Cache (60 s TTL) | ~1 ms | ≤ 60 s stale | Low | ✓ for product pages |
| More read replicas | ~5–10 ms | Replication lag, usually < 1 s | Higher | If freshness matters more |
| Bigger primary DB | ~5–10 ms | Exact | Highest, has a ceiling | Short-term relief |
This is the idea behind ATAM-style reasoning (Architecture Trade-off Analysis Method): make the attributes explicit and score options against them.
Justifying eventual consistency
Ask what happens if a user sees slightly old data. For a like counter or a feed, a few seconds of delay is harmless, and you gain availability and lower latency. For a bank balance it is not. Add guardrails where needed, like read-your-writes: a user always sees their own changes immediately, even if others see them a moment later.
Talking about a real project (STAR-style). Context → options you considered → choice and its cost → result with a number. “We cached repeated LLM answers, cut model cost by 40%, and skipped the cache for time-sensitive questions.”
Key terms
| Term | Meaning |
|---|---|
| Trade-off | gain one quality, pay in another |
| Quality attribute | latency, availability, cost … |
| Eventual consistency | replicas converge, reads may lag |
| Read-your-writes | you always see your own changes |
| ATAM | scoring options against ranked attributes |
| Mitigation | how you limit the cost you accepted |
Interview questions
Each question is tagged by kind: Basic (definitions), Scenario (apply it to a system) and Tricky (the follow-ups interviewers use to go deeper). Answer out loud before you open the answer.
How do you justify a design choice? (Basic)
What a strong answer covers
Name the choice, the requirement that drives it, what you give up, and how you limit that cost. Then say what would make you choose differently.
When is eventual consistency acceptable? (Basic)
What a strong answer covers
When stale data is harmless for that feature (likes, feeds, view counts), and you gain availability or latency. Add read-your-writes so users see their own changes.
What's wrong with answering “it depends”? (Basic)
What a strong answer covers
Nothing as a start, but it isn't an answer. Say what it depends on (the ranked requirements), score the options, and commit.
Describe a real trade-off from your work. (Scenario)
What a strong answer covers
Use context, options, choice and cost, result with a number. For example: cached repeated LLM answers, cut cost by 40%, accepted stale answers for 1 hour, bypassed the cache for time-sensitive queries.
Cache or read replicas for a read-heavy product catalogue? (Scenario)
What a strong answer covers
A cache with a short TTL if slightly stale data is fine: cheaper and ~1 ms reads. Read replicas if data must be fresher or queries are too varied to cache. Often both: replicas behind a cache.
Your team wants microservices for a 3-person startup. How do you respond? (Scenario)
What a strong answer covers
Weigh flexibility against operational cost. With 3 engineers, a modular monolith is usually faster to build and run; split services later where scaling or team boundaries demand it.
A like counter shows 1,203 to one user and 1,207 to another. Is that a bug? (Tricky)
What a strong answer covers
Not if the requirement allows eventual consistency for likes. It becomes a bug only if the product needs exact counts (e.g. billing by likes), then you need strongly consistent counting.
How do you know which trade-off the interviewer wants you to make? (Tricky)
What a strong answer covers
You don't guess: you derive it from the requirements you agreed on, state it, and offer the alternative. Interviewers score the reasoning, not a specific pick.
Common mistakes & troubleshooting
- Presenting a choice as having no downside.
- Stopping at “it depends”.
- Naming a technology instead of the property you need from it.
- One consistency level for every feature.
Free PDF notes
Download these notes as a printable PDF, with every diagram: SD-A-005.pdf. All Phase 1 notes in one file: Phase 1, Core Fundamentals (PDF).
Next
Continue with Lesson 06: Vertical Scaling.