How to discuss trade-offs
Use a simple pattern: Option A vs Option B → when to pick each → what you are giving up.
Trade-off framing template
- State the decision ("SQL vs NoSQL for the timeline store").
- Name two realistic options with one-line pros/cons each.
- Tie the pick to your stated requirements (read-heavy, flexible schema, etc.).
- Acknowledge what you sacrifice and how you mitigate it.
| Aspect | Push timeline | Pull timeline |
|---|---|---|
| Read latency | Fast — precomputed feed | Slower — assemble on read |
| Write cost | High for celebrities | Low — one write per post |
| Consistency | Stale until fan-out completes | Fresh on every read |
| Best for | Average users, read-heavy | Few followers or write-heavy |
Read latency
Push timelineFast — precomputed feedPull timelineSlower — assemble on readWrite cost
Push timelineHigh for celebritiesPull timelineLow — one write per postConsistency
Push timelineStale until fan-out completesPull timelineFresh on every readBest for
Push timelineAverage users, read-heavyPull timelineFew followers or write-heavy
Neither approach wins everywhere — hybrid models are common in production.
CP systems: bank ledgers. AP systems: social feeds, DNS.
Recurring trade-off pairs
| Decision | Favour A when | Favour B when |
|---|---|---|
| Consistency vs availability | Financial balances, inventory | Social feeds, analytics |
| Latency vs throughput | Real-time bidding | Batch ETL pipelines |
| Normalisation vs denormalisation | Frequent updates, small rows | Read-heavy, stable snapshots |
| Sync vs async processing | User waits for result | Fire-and-forget, email, analytics |
| Monolith vs microservices | Small team, early product | Independent deploys, clear boundaries |
Consistency vs availability
Favour A whenFinancial balances, inventoryFavour B whenSocial feeds, analyticsLatency vs throughput
Favour A whenReal-time biddingFavour B whenBatch ETL pipelinesNormalisation vs denormalisation
Favour A whenFrequent updates, small rowsFavour B whenRead-heavy, stable snapshotsSync vs async processing
Favour A whenUser waits for resultFavour B whenFire-and-forget, email, analyticsMonolith vs microservices
Favour A whenSmall team, early productFavour B whenIndependent deploys, clear boundaries
Common interview mistakes
Mistakes that sink answers
- Buzzword soup — naming Kafka, Redis, and Kubernetes without explaining why this problem needs them.
- No requirements — designing before clarifying scale, consistency, or scope.
- Single point of failure — one database, one region, no health checks mentioned.
- Ignoring failure — happy path only; no retries, timeouts, or degradation.
- Over-engineering — microservices and event sourcing for 1K QPS.
- Under-engineering — single Postgres for 1M write QPS.
- No numbers — "lots of users" instead of estimated QPS.
- Silent diagram — drawing boxes without narrating data flow.
The over-engineering trap
Junior candidates often reach for distributed systems too early. A monolith on a managed database handles millions of users when the workload is simple.
1K QPS, 5-person team, CRUD app
→ Monolith + managed Postgres + CDN for static assets
→ NOT: 12 microservices, service mesh, custom consensus
The under-engineering trap
The opposite mistake: assuming one server forever. If your estimation shows 100K read QPS, say where caching and horizontal scaling enter the design.
# Signs you need more than one box
# - p99 latency grows linearly with traffic
# - DB CPU pegged at 90% during normal hours
# - Single AZ outage = full outage
Communicating uncertainty
You will not know every detail. Strong candidates say:
- "I'd validate this with a load test before committing."
- "At this scale I'd prototype both approaches with a spike."
- "I'd check the team's operational experience with Cassandra before choosing it."
That is preferable to false confidence or freezing up.
Recovery tactics mid-interview
When you are stuck
- Restate requirements — often the answer is in an NFR you skipped.
- Simplify — drop a feature to buy time for the core path.
- Ask a narrowing question — "Should I focus on the write path or read path?"
- Think aloud — silence is worse than imperfect reasoning.
Checklist before you finish
Before the session ends, verify you have covered:
tradeoff_review:
- named_at_least_one_explicit_tradeoff
- linked_choice_to_stated_nfr
- mentioned_failure_mode_or_degradation
- estimated_order_of_magnitude_scale
- stated_one_thing_you_would_do_next
Quick recall
Everything you need if you only revisit this box.
- Frame trade-offs as A vs B, when to pick each, and what you give up.
- Tie every major component to a stated requirement — avoid buzzword soup.
- Over-engineering (microservices at 1K QPS) and under-engineering (one DB at 1M QPS) are both failures.
- Name failure modes, retries, and monitoring — not just the happy path.
- Uncertainty is fine if you say how you would validate the decision.
- Use a parking lot for deferred features to control scope under time pressure.
Test yourself
Answer these before moving on — recall is what makes it stick.