Trade-offs in System Design
Every architecture choice optimizes something and gives up something else.
Definition
In engineering, trade-off means you cannot maximize all qualities simultaneously. Good design is not “best technology”; it is context-fit technology chosen against business priorities and operational constraints.
Why It Matters
- Prevents over-engineering and premature complexity.
- Improves communication with product/stakeholders using explicit decision rationale.
- Reduces rework because assumptions and constraints are documented early.
When to Use
- Any architecture decision involving competing goals.
- Interview/system design rounds where no perfect solution exists.
- Migration planning (monolith -> microservices, sync -> async, etc.).
When NOT to Use
- Do not over-analyze trivial low-impact choices.
- Avoid abstract debates without SLOs, load assumptions, or business constraints.
Code Variations
Scenario: Product details API (high read traffic)
Option A: cache-aside with TTL 5 mins
+ very fast reads, lower DB load
- possible stale data for 5 mins
Option B: read directly from DB
+ freshest data
- higher latency/cost under load
Decision:
Use Option A + explicit cache invalidation on critical price updates.Scenario: payment gateway transient failures
Option A: aggressive retries (5 attempts)
+ may recover more transient failures
- can amplify outage and increase latency
Option B: bounded retries (2 attempts + breaker)
+ protects system under outage
- some requests fail faster
Decision:
Option B with idempotency key + fallback queue for manual recovery.Scenario: dashboard reads are 50x writes
Option A: single normalized DB model
+ simple operations
- read queries become expensive
Option B: CQRS (write model + read projection)
+ fast read paths, scalable dashboards
- eventual consistency + operational complexity
Decision:
Adopt CQRS only for high-traffic report endpoints first.Common trade-offs you must reason about
| Aspect | Option A | Option B |
|---|---|---|
| Consistency vs Availability | Strong consistency (fewer stale reads) | Higher availability under partitions (eventual consistency) |
| Latency vs Cost | Low latency via caching/replicas/provisioning | Lower infra cost with fewer resources |
| Simplicity vs Flexibility | Simple architecture, faster delivery | More extensible but higher complexity |
| Throughput vs Ordering | High parallelism, possible reorder | Strict ordering with lower parallel throughput |
| Write optimization vs Read optimization | Normalized writes, strong integrity | Denormalized reads, faster queries |
Common Confusions Cleared Up
Trade-off is intentional optimization against objective metrics. Compromise is often unstructured middle-ground without clear success criteria.
Quick solutions can be valid if time-to-market is primary goal, but record debt and define future refactor triggers.
Variations / Implementations
How to handle trade-offs (practical framework)
1) Define primary goal (p99 latency? consistency? cost?). 2) List constraints (traffic, team, deadline, compliance). 3) Propose 2–3 options. 4) Score options against SLOs. 5) Choose now + document revisit trigger.
Decision record mindset
Write short ADR-style notes: context, options considered, chosen option, consequences, rollback path, and conditions under which you will re-evaluate.
Evolve architecture, do not front-load everything
Start with the simplest design that meets current SLOs. Add complexity only when metrics show clear pressure (latency, error rate, cost, throughput).
Common Mistakes / Anti-Patterns
- Choosing tech by trend without workload fit.
- Ignoring operational cost/complexity in design decision.
- No measurable success criteria for chosen architecture.
- One-way decisions with no rollback/revisit plan.