Chapter 19: CAP Theorem and Consistency Models in Practice
You covered CAP in the DB guide. Here's the practical system design perspective:
In Practice: It's About Latency
The real trade-off isn't "pick 2 of 3." It's: during a network partition, do you return stale data (AP) or an error (CP)?
Consistency Spectrum
Strong ◄────────────────────────────────────────► Eventual
(always latest) (converges over time)
Banking Shopping Cart Social Feed DNS
(must be exact) (last-write-wins OK) (stale OK) (hours stale OK)
Practical Patterns
- Read-your-writes: after writing, YOUR reads see the write (others may not yet)
- Monotonic reads: you never see older data after seeing newer data
- Causal consistency: if A causes B, everyone sees A before B
System Design Implications
| Choice | Architecture | Example |
|---|---|---|
| Strong consistency | Single leader, synchronous replication | Bank account balance |
| Eventual consistency | Multi-leader/leaderless, async replication | Social media likes count |
| Mixed | Strong for critical paths, eventual for others | Most real systems |
💡 Practical Rule
Use strong consistency for money/inventory/auth. Use eventual consistency for feeds/counters/analytics. Most systems are a mix.