Eventual consistency guarantees that replicas eventually converge to the same state. Until then, replication lag, a network partition, or an unavailable node can leave them with different values. A client may even see different versions on consecutive reads if those reads reach different replicas. This is a weaker guarantee than linearizability, which makes access appear as though there were only one copy. section 4.3.2 section 4.1
Three replicas, three different views
In a three-replica key–value store, put(A, 1) reaches replicas 1 and 2 but not replica 3. A later put(B, 2) reaches all three, so replica 3 has B but still lacks A. Then put(A, 3) reaches replica 1 while replica 3 receives the earlier value A = 1. At that moment, reads of A can return 3, 1, or no value, depending on the replica. section 4.3.2
Figure 4.2 An example of an eventually consistent key–value store with three replicas
The three-replica timeline makes the temporary differences in replica state visible. section 4.3.2
The attraction is latency: accepting a write locally avoids waiting for coordination with other nodes. CDNs make a familiar trade-off of this kind because users can tolerate temporarily different versions of cached assets. The cost is that an acknowledged update need not be visible at every replica yet; applications must account for stale reads. section 4.3.2 section 4.5
Several designs expose this trade-off:
- With asynchronous primary–replica replication, the primary acknowledges a write before sending it to replicas. Replication runs in the background, so the copies can temporarily disagree. section 4.5
- With leaderless replication, writes can occur locally without a leader enforcing their order. Quorum acknowledgements can provide some consistency, while CRDTs can help address conflicts without making the system strongly consistent. section 4.4.3
- With optimistic client updates, a local shadow write queue propagates changes asynchronously. Other clients may read stale data before those changes arrive. section 11.3.3
Observe convergence in a key–value store
Run a Rust primary and replica. Write a = 1 and b = 2 to the primary; reads on the unjoined replica return “Not found.” Issue JOIN localhost:8080 to receive a snapshot, then read both values from the replica. A subsequent write of c = 3 to the primary is pushed to the replica. This illustrates the replication flow, not durability or behavior under errors. section 4.8
Choose the guarantee against the application's tolerance for differing or stale reads. Stronger consistency can require more coordination and higher latency; synchronous replication, for example, delays acknowledgement until replication completes. section 4.1 section 4.5
