The spectrum
diagram
| Model | Guarantee | User-visible example |
|---|---|---|
| Linearizable | Behaves like a single copy; reads see the latest completed write | Bank balance after a transfer |
| Causal | Effects are seen after their causes | A reply is never visible before its question |
| Read-your-writes | You always see your own updates | Save an entry, refresh, see the change |
| Monotonic reads | You never go back in time | A list doesn't "un-publish" on refresh |
| Eventual | Replicas converge if writes stop | Like counts, search index, CDN |
Practical techniques
- Read-your-writes: read from the primary for N seconds after a user writes, or pass a version/timestamp token and read from a replica only if it's caught up.
- Monotonic reads: pin a user's session to one replica.
- Causal: MongoDB causally-consistent sessions; vector clocks or Lamport timestamps in custom systems.
- Make eventual consistency visible: "Publishing… (usually under a minute)" is better than silent staleness.
Cheatsheets
The whole topic on one page. Click to open full screen.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Distributed Systems & DataUnderstood
CAP & PACELC Theorems
During a network partition you choose consistency or availability; when there's no partition you still trade latency against consistency.
Intermediate5 sources
Distributed Systems & DataUnderstood
Replication
Keep copies of data on multiple nodes for availability, durability and read scaling — single-leader, multi-leader and leaderless, sync vs async.
Intermediate4 sources
Architecture PatternsUnderstood
CQRS (Command Query Responsibility Segregation)
Use one model to change data (commands) and a different, optimised model to read it (queries) — often kept in sync by events.
Advanced4 sources