Trade-offs: The Architect's Core Skill
Here's the uncomfortable truth about system design: there is no perfect system. Every architectural decision is a trade-off. Choosing one thing means giving up another. The skill isn't finding the "right answer" — it's finding the best trade-off for your context.
"There are no solutions. There are only trade-offs." — Thomas Sowell
The Major Trade-off Axes
Most design decisions fall along these fundamental tensions:
Understanding Each Trade-off
Consistency vs. Availability
Consistency: Every read returns the most recent write. All nodes see the same data at the same time.
Availability: Every request gets a response, even if some nodes are down.
The CAP theorem proves you can't have both during a network partition. You must choose.
Latency vs. Throughput
Low latency: Each individual request is fast (optimize for response time).
High throughput: The system processes many requests total (optimize for batch efficiency).
Batching improves throughput but increases latency for individual items. Streaming gives low latency but less efficient resource use.
Simplicity vs. Flexibility
Simplicity: Easy to understand, fewer moving parts, faster to build.
Flexibility: Handles more use cases, adapts to change, but more complex.
A monolith is simple but rigid. Microservices are flexible but operationally complex. Start simple, add complexity only when needed.
Cost vs. Performance
Low cost: Fewer servers, cheaper storage, shared resources.
High performance: More servers, faster storage, dedicated resources.
You can always make it faster by spending more money. The question is: what performance level is "good enough" for your users?
A Framework for Trade-off Decisions
The 4-Step Process
- Understand constraints: What are the hard requirements? (latency SLAs, budget limits, team size)
- Identify options: What are the 2-3 realistic architectural choices?
- Evaluate against requirements: Which option best satisfies the NFRs that matter most?
- Document the decision: Write down why you chose it and what you're giving up (future-you will thank you)
Real-World Example: Netflix
Netflix chose: Availability over Consistency
When you browse Netflix, you might see slightly stale recommendations or a show that was just removed still appearing briefly. Netflix accepts this because the alternative — showing "Service Unavailable" while waiting for all nodes to agree — is far worse for their business.
The trade-off: Users occasionally see stale data, but the service never goes down. For a streaming service, uptime matters more than perfect accuracy of recommendations.
- ✅ 99.99% availability worldwide
- ✅ Sub-second page loads
- ⚠️ Recommendations may be slightly out of date
- ⚠️ Recently removed content may briefly appear
Banking chose: Consistency over Availability
When you transfer money, your bank will reject the transaction rather than risk showing you an incorrect balance. They'll show "Service temporarily unavailable" rather than let you overdraw or see stale data.
The trade-off: Occasionally slow or unavailable, but your money is never wrong. For financial systems, correctness is non-negotiable.
- ✅ Balance is always accurate
- ✅ Transactions are never lost or duplicated
- ⚠️ Transfers may take seconds to confirm
- ⚠️ System may be briefly unavailable during network issues
Make the Trade-off
Scenario: Choose the right trade-off for each system.