Consistency models
What a distributed store promises about when a write becomes visible and in what order — the spectrum between “every reader sees the same thing immediately” and “everyone converges eventually.” Documented from podc-lecture-notes.
CAP, with its model attached
The trade press states CAP as pick two of three. The notes give the provenance instead: introduced by Fox and Brewer (1999), popularised by Brewer’s 2000 talk, and proven by Gilbert and Lynch (2002) for the asynchronous model. The same authors showed that in a partially synchronous system the consistency requirement can be relaxed to obtain availability and partition tolerance.
Two things follow that the slogan loses. It is a theorem about a specific failure model, so quoting it without saying which model is quoting nothing. And the useful engineering move is not choosing two letters — it is weakening consistency by a stated amount in exchange for staying available under partition.
The weaker guarantees, named
- Eventual consistency — no ordering promise, only convergence if updates stop. The notes’ worked example is Bitcoin, which is a useful choice: a system whose entire design is public and whose consistency guarantee is genuinely eventual.
- Causal consistency — “operations that potentially are causally related are seen by every node of the system in the same order. Concurrent writes are not causally related, and may be seen in different orders by different nodes.” The practical middle: preserve cause and effect, allow genuinely concurrent work to be ordered differently by different readers.
Quorum systems are the other half of the picture — read and write sets that must intersect, priced by load and work, with byzantine variants for arbitrary faults. A quorum system is how a store converts a consistency promise into a per-operation cost.
Why this spoke needed it
rethinking-data-client-event-sourcing arrived arguing merge semantics for the client case — event sourcing against CRDTs — and this wiki recorded that it came from someone who maintains an event-sourcing framework, with no neutral treatment behind it. Causal consistency is the vocabulary that argument was missing: what is being merged, and which orderings a system is entitled to disagree about.
It also frames the local-first-architecture thread. Local-first is not a rejection of consistency; it is a choice of a named weaker model, made because the alternative under partition is being unavailable.
What is not here
No engine’s actual guarantee. Which model turso, vitess or planetscale provides, under which failure conditions, is unsourced in this corpus — and vendors describe these guarantees in prose rather than in the terms above.
Related
podc-lecture-notes · consensus · rethinking-data-client-event-sourcing · local-first-architecture · event-sourcing · operational-databases