Core idea
CAP gives you the binary. In practice, consistency is a spectrum. You need to know the points on that spectrum and when each is appropriate.
Mental model
Think of Google Docs: you and a colleague edit the same doc simultaneously. Strong consistency = every edit is applied in one agreed order and everyone sees the latest version before continuing (simple to reason about, but every keystroke waits on coordination). Eventual consistency = both edits go through, conflicts resolved automatically (what Google Docs actually does). Causal consistency = your reply to someone’s comment only appears after their comment does (ordering guarantee without full consistency).
Why it matters
- Different parts of your system can use different consistency levels
- Choosing wrong consistency = either data loss or terrible performance
- Senior engineers think in these terms naturally
What to know
- Strong consistency: read after write always sees latest — slowest, safest
- Linearizability: operations appear instantaneous — single-node behavior on distributed system
- Sequential consistency: all nodes see same order — weaker than linearizable
- Causal consistency: causally related ops in order — good for social apps
- Eventual consistency: converges eventually — highest availability, lowest latency
- Read-your-writes: you always see your own writes — minimum for good UX
Common traps
- Confusing eventual consistency with ‘anything goes’ — it still has guarantees
- Not providing read-your-writes for user-facing writes (user sees their post disappear)
- Applying strong consistency to analytics — waste of resources
Recognise it
Recognition trigger: Social/content systems → eventual consistency. Financial transactions → strong consistency. Your own writes shown to you → read-your-writes minimum. Comments/replies → causal consistency.
Practice question
A user updates their profile photo. When should they see the new photo? When should others see it? Are these the same answer?
Apply at work
Answer these for the system you work on.
Go deeper
- Chapter 9: Consistency and Consensus · Designing Data-Intensive Applications (Kleppmann), book
- Chapter 5: Replication: problems with replication lag · Designing Data-Intensive Applications (Kleppmann), book