Eventual Consistency

What is it: A consistency model where, if no new updates are made to a data item, eventually all replicas will converge to the same value. There is no guarantee of how long "eventually" takes.

Why: strong consistency in a distributed system requires coordination (locks, consensus protocol) on every write — expensive in terms of latency and availability. Eventual consistency allows replicas to diverge temporarily and converge asynchronously, maximizing write throughput and availability.

Where it appears: DNS propagation (a DNS record change may take minutes to hours to propagate globally), Cassandra multi-region replication, DynamoDB global tables, Redis async replication.

graph LR w1["Write X=5 to Replica A"] --> a["Replica A: X=5"] w2["Write X=7 to Replica B<br/>(concurrent, different region)"] --> b["Replica B: X=7"] a -->|"async replication, some delay"| conv["Conflict detected on sync:<br/>both claim to be current"] b -->|"async replication, some delay"| conv conv --> resolved["Resolved (LWW / vector clock / CRDT)<br/>-> both replicas converge to ONE value"]

Conflict resolution: when two replicas accept concurrent writes to the same key (during a partition), they diverge. On partition heal, they must reconcile: Last-Write-Wins (LWW) uses timestamps — whoever has the higher timestamp wins; simple but can lose data. Vector clocks track causality — concurrent writes are flagged for application-level merge (e.g., shopping cart: union of items). CRDTs (Conflict-free Replicated Data Types) are data structures designed to merge automatically (counters, sets).

Trade-offs: eventual consistency requires application logic to handle stale reads and conflict resolution. It is correct for many use cases (user preferences, social media feeds) but wrong for financial balances and inventory (where stale reads cause real money loss).

Common pitfall

Assuming "eventually" means "within milliseconds" — the model gives no bound at all on convergence time by definition; under normal operation it's often fast, but during a partition or heavy load it can be seconds, minutes, or (in a pathological case with no partition healing) indefinite. Building logic that assumes a specific convergence window (e.g. "the user's own write will definitely be visible within 100ms") is building on a guarantee the model never made — see Replication for the concrete read-after-write failure mode this causes and how to route around it.