Skip to content
ROOT
STUB

Eventual Consistency

The pattern: if writes stop, all replicas eventually converge to the same state. During writes, reads may see different values. The price of choosing A over C in CAP — but bounded forms (read-your-writes, monotonic reads, causal, session) make it useful in practice.

The trade-off: simplicity vs. correctness. Eventually consistent systems are simpler to scale (no global coordination per write) but harder to reason about (when does my read see my write?). Application code often has to compensate (idempotency, conflict resolution, “last write wins” with monotonic timestamps). The real question isn’t “consistent or eventual?” but “how eventual, and where do I bound it?”

[Deepen Year 2 Phase 8 with DDIA Ch. 5 + a Cassandra-or-similar exercise.]

  • CAP and PACELC — eventual consistency is the operational expression of choosing A / EL.
  • Replication — leaderless and multi-leader replication produce eventual consistency by construction.
  • CRDTs — the principled way to merge concurrent writes instead of LWW.
  • Idempotency — what application code uses to compensate for “did my write land?”
  • Distributed time — bounded consistency only makes sense under some clock model.
  • Caching — cache invalidation is “eventual consistency in a smaller font.”

First touched in Year 2 Phase 8; felt operationally across Year 3 data tier work.