Eventual Consistency And Convergence
Strong consistency means every read sees the latest write, which requires coordination that costs latency and availability. Many systems choose eventual consistency instead. They promise that if writes stop, all replicas will eventually agree, but they do not promise when, and a read may temporarily return stale data.
The value is availability. A replica can accept reads and writes without contacting its peers, so it stays up during a network partition. The propagation of updates happens in the background. Between a write on one replica and its arrival at another, the two disagree.
Convergence is the harder promise. It is not enough that updates eventually arrive, they must combine to the same final state regardless of the order in which replicas receive them. If two replicas apply concurrent updates in different orders and end up different, the system has not converged. Achieving convergence needs conflict resolution rules that are commutative, so order does not matter.
- Eventual Replicas agree once activity quiets down.
- Convergent They reach the same state independent of message order.
- Stale reads are the price paid for staying available.
Conflict free replicated data types are designed so that merges are always commutative and associative, guaranteeing convergence by construction.
Key idea
Eventual consistency promises replicas agree once writes stop, and convergence further requires that concurrent updates merge to the same state no matter what order each replica receives them.