Eventual Consistency
Also known as: convergence, BASE
Eventual consistency guarantees only that if writes stop, all replicas eventually converge to the same value. It says nothing about how long that takes or what a client sees meanwhile — a read may return a value older than one the same client already saw, unless a stronger session guarantee is layered on top.
Last reviewed · Part of the Architecture Glossary
In practice
"Eventually" is not a number, and that is the whole problem with the term. In a healthy single-region cluster convergence is typically single-digit milliseconds. Under cross-region replication it is tens to hundreds. Under a partition it is until the partition heals — which could be an hour.
The session guarantees that make it usable are worth naming separately, because most stores let you pick them:
- Read-your-writes — you see your own updates.
- Monotonic reads — you never see time go backwards.
- Consistent prefix — you never see an effect before its cause.
Plain eventual consistency gives you none of these. A user edits their profile, the read hits a lagging replica, and the app shows the old name — a bug report that reproduces one time in fifty and is invisible in staging.
When it matters
Read-heavy display paths, analytics, caches, cross-region replicas, CRDT-backed collaborative state, and anything using replication lag to scale reads.
Common mistake
Reading a value back immediately after writing it, from a replica pool. Route the read-after-write to the primary, or pin the session to the replica that has caught up to the write's LSN — do not hope the lag is small.
See also
- LinearizabilityLinearizability is the strongest single-object consistency model: every operation appears to take effect instantaneously at some point between its invocation and its response, and once a write is visible to any client it is visible to all.
- Read-Your-Writes ConsistencyRead-your-writes consistency guarantees a client always sees its own completed writes, even while other clients may still see stale data.
- Replication LagReplication lag is the delay between a write committing on the primary and becoming visible on a replica.
- CAP TheoremThe CAP theorem states that when a network partition occurs, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response).