Part 5 · 2 chapters · ~16 min
Consistency Models
The consistency ladder: linearizable with a timeline picture, sequential, causal and eventual, and choosing per operation with the defaults and options of real stores; then CAP as behaviour during a partition and PACELC as the latency trade the rest of the time.
10
Linearizable, sequential, causal, eventual
a contract about what reads may return
- Linearizable: behaves like one copy, in real time.
- In a picture: once anyone has seen the new value, nobody sees the old one.
- Sequential: everyone agrees on one order, though not necessarily in real time.
- Causal: causes are seen before their effects. It is the strongest model that stays available during a partition.
- Eventual: replicas converge once writes stop. Nothing is promised before that.
- Choose per operation and pay for strength only where an anomaly would be a bug.
| store | default | stronger option |
|---|---|---|
| Postgres (single primary) | linearizable on the primary; replicas lag | read from the primary, or wait for the LSN |
| DynamoDB | eventually consistent reads | ConsistentRead: true (same region), transactions |
| Cassandra | per query: ONE, QUORUM, ALL… | QUORUM writes + QUORUM reads; LWT (Paxos) for compare-and-set |
| Cosmos DB | session | bounded staleness, strong |
| S3 | strong read-after-write (since 2020) | conditional writes (If-Match / If-None-Match) |
| Spanner, CockroachDB | serializable, linearizable | stale reads available for lower latency |
THE CONSISTENCY LADDER
linearizable, sequential, causal and eventual: what each promises about the reads you can observe
swipe the figure sideways, or tap expand for full screen
1/6
linearizable
Linearizable: the system behaves as if there is one copy and every operation takes effect atomically at some instant between its start and end. Once a write completes, every later read (by anyone, anywhere) sees it or something newer. This is what people mean by "strongly consistent"; it is what a lock, a leader election or an account balance check needs.
11
CAP and PACELC
what a partition forces, and what latency costs
- The setup: replicas in two places.
- A partition is not optional. Sooner or later one happens.
- CP: refuse requests where there is no quorum. Nothing stale, nothing conflicting.
- AP: keep serving on both sides and reconcile later.
- PACELC: the rest of the time, the trade is latency against consistency.
- In practice: money is CP, feeds are AP, and many stores let you tune per operation.
the misreading
"CAP means pick two" suggests you could build a CA system. On a real network there is no such thing, because partitions happen. What you choose is behaviour during a partition (refuse or diverge), and behaviour the rest of the time (wait or answer fast). A system that never says which has made the choice anyway, by accident.
CAP AND PACELC
what a network partition forces you to give up, and the latency trade that applies the rest of the time
swipe the figure sideways, or tap expand for full screen
1/6
the setup
The setup: two replicas, one in Lagos and one in London, both serving reads and writes of an account's balance. Normally they replicate to each other and agree.