Module 13 · Distributed fundamentals · Lesson 6 of 18
Consistency models
What a replicated system promises about the order and visibility of writes: linearizability, sequential, causal, read-your-writes, monotonic reads and eventual consistency. What each costs in latency and availability.
The video walkthrough is part of Pro.
See what Pro includesWhy it matters
"Consistent" means something different to a database engineer (ACID's C), a distributed-systems engineer (ordering of operations across replicas) and a product manager (users do not see weird things). This lesson is about the second meaning: when there are several copies of data, what can a reader observe about writes that happened elsewhere? Picking the right model per feature is the difference between a system that is fast and correct where it matters and one that is slow everywhere or wrong somewhere.
The idea
A consistency model is the contract between a replicated store and its clients about which values a read may return given the writes that have occurred. Stronger models give fewer surprises and cost more coordination; weaker models give availability and latency and push reasoning onto the application.
| Model | Promise | Anomaly it rules out | Cost |
|---|---|---|---|
| Linearizable (strong) | Every operation appears to happen instantaneously at one point between its start and end, in one global order consistent with real time | Any stale read; two clients disagreeing about the current value | Coordination on every operation: a leader or quorum round trip; unavailable on the minority side of a partition |
| Sequential | All clients see the same order of operations, but that order need not match real time | Clients seeing different orders | Nearly as expensive as linearizable in practice |
| Causal | If write B depended on (read) write A, every reader sees A before B; concurrent writes may be seen in any order | Seeing a reply before the message it answers | Version vectors or dependency tracking; available under partition |
| Read-your-writes | A client always sees its own writes | Posting a comment and not seeing it | Route the client to the primary or wait for replication of its own writes |
| Monotonic reads | A client never sees time go backwards | Refreshing and seeing an older state | Pin the client to one replica |
| Eventual | If writes stop, all replicas converge to the same value | None of the above; anything may be observed temporarily | Cheapest; always available; conflicts must be resolved |
The session guarantees
Read-your-writes, monotonic reads, monotonic writes and writes-follow-reads are session guarantees: promises to a single client rather than globally. They are cheap to provide (route a session to one replica, or track the version a client has seen and wait for replicas to reach it) and they remove most of the anomalies users actually notice. A system can be eventually consistent globally and still give every user a coherent personal view. This is the pragmatic middle that most consumer products live in.
Causal consistency
Causal consistency is the strongest model that remains available under partition. It preserves cause and effect: if you read a question and then write an answer, nobody sees the answer without the question. Concurrent, unrelated writes may be observed in different orders on different replicas, which is harmless. Implementing it needs dependency tracking (vector clocks or explicit version dependencies), covered in the Time and Ordering lessons; systems like MongoDB (causal sessions) and research systems such as COPS provide it.
What products offer
Single-leader databases with synchronous replication are linearizable for reads from the leader; reads from asynchronous replicas are eventually consistent with lag, which is why read-your-writes routing exists. Spanner and CockroachDB offer linearizable (externally consistent) transactions across regions using synchronized clocks and consensus. Dynamo-style stores and Cassandra are tunable: per operation you choose how many replicas must agree, so QUORUM reads after QUORUM writes give strong consistency for a key and ONE gives eventual. ZooKeeper and etcd are linearizable for writes and offer linearizable reads on request. Object stores are now read-after-write consistent.
PACELC and choosing per feature
CAP describes behaviour under partition; PACELC adds the normal case: Else, trade Latency against Consistency. Even with no partition, linearizable operations wait for coordination, so choosing strong consistency costs latency every day. The decision is per feature: balances, inventory counts, unique usernames and leader state want linearizability; feeds, likes, view counts and presence want eventual with session guarantees; collaborative documents want causal plus convergence (CRDTs or OT).