Ask an engineer if their database is "consistent" and you'll get a yes. Ask which consistency model and the room gets quiet. That silence is expensive: most "we saw stale data" bugs, most "the test passed but production didn't" mysteries, and a good share of double-processed jobs come down to teams assuming one consistency model while running under another.
Here's the whole landscape in one diagram — a single-leader replicated store where the model you get depends entirely on where and how you read:
This is a real techdiagrams document — download the JSON and import it into the editor via File → Import.
The spectrum, strongest to weakest
Linearizable (a.k.a. strong consistency). Every operation appears to happen at a single instant in real time; once a write is acknowledged, every subsequent read — from anyone, anywhere — sees it. In the diagram, that's reading from the leader after an acknowledged commit. It's the model your intuition assumes, and it's the expensive one: it requires coordination (consensus or a single serialization point), which is why it costs latency and why it stops being available during partitions. Use it where the answer must be the answer: balances, inventory decrements, leader election, uniqueness checks.
Sequential consistency. Everyone sees all operations in the same order, but that order isn't required to match real-time. Two clients never disagree about history, but a just-committed write may not be visible "now." It's linearizability minus the wall-clock promise — cheaper, and often all your logic actually needs.
Causal consistency. Order is guaranteed only where it means something: if event B was caused by event A (a reply to a message, an edit after a read), everyone sees A before B. Unrelated writes may interleave differently for different observers — and that's fine, nobody can tell. This is the sweet spot for social feeds, comments, and collaborative apps: the green annotation in the diagram — "the reply never appears before the question" — is usually the promise users actually care about.
Session guarantees — the practical middle. Weaker than causal globally, but strong for you:
- Read-your-writes — after you save, you see it saved (others may lag). Implemented by pinning your session to the leader, or to a replica known to have caught up past your write.
- Monotonic reads — you never travel back in time: having seen version 5, you'll never be served version 4 by a laggier replica.
- Consistent prefix — you may see an old state, but never a scrambled one.
Most product bugs blamed on "eventual consistency" are actually missing session guarantees. Users rarely notice global staleness; they always notice their own edit vanishing.
Eventual consistency. The only promise: stop writing, and replicas converge... eventually. In the diagram it's the red path — reading a follower that's two seconds behind returns x=1 after x=2 was acknowledged. This isn't a defect; it's a deliberate trade that buys availability and latency. It's perfect for view counts, avatars, and caches — and catastrophic for money.
Tunable quorum (Dynamo-style). Leaderless stores make staleness a dial: with N replicas, write to W and read from R. If R + W > N, every read set overlaps every write set — you'll always touch at least one fresh replica. W=2, R=2, N=3 is the classic. Slide W down for write speed, R down for read speed, and know exactly what you gave up (we've covered what happens when a replica is down in the hinted handoff post).
One honest clarification: isolation ≠ consistency
Snapshot isolation and serializability (the SERIALIZABLE in your SQL) answer a different question — how concurrent transactions interleave on one system — while consistency models answer how replicas agree across machines. They collide in distributed SQL databases, but keep the vocabularies apart: "we run snapshot isolation" says nothing about whether your read replicas serve stale rows.
The takeaway: choose per operation, not per system
The most useful reframe: consistency is not a property of your database — it's a property of each read path. The same cluster in the diagram serves linearizable reads (leader), eventual reads (follower), and read-your-writes (pinned session) simultaneously. Mature systems mix them deliberately: checkout reads the leader, the product page reads a follower, your own profile edits read your session's replica.
So the design review question is never "is our system consistent?" It's: for this endpoint, what staleness can we tolerate — and which read path buys exactly that, no more? Every notch of consistency you don't need is latency and availability you're giving away.
Import the diagram into techdiagrams.net, and the read paths become something you can annotate, extend and argue about — which is what a consistency decision deserves.