[Avg. reading time: 6 minutes]
Eventual consistency
Eventual consistency is a consistency model used in distributed systems (like NoSQL databases and distributed storage) where updates to data may not be immediately visible across all nodes. However, the system guarantees that all replicas will eventually converge to the same state — given no new updates are made.
Unlike stronger models like serializability or linearizability, eventual consistency prioritizes performance and availability, especially in the face of network latency or partitioning.
Simple Example: Distributed Key-Value Store
Imagine a distributed database with three nodes: Node A, Node B, and Node C. All store the value for a key called "item_stock":
Node A: item_stock = 10
Node B: item_stock = 10
Node C: item_stock = 10
Now, a user sends an update to change item_stock to 15, and it reaches only Node A initially:
Node A: item_stock = 15
Node B: item_stock = 10
Node C: item_stock = 10
At this point, the system is temporarily inconsistent. Over time, the update propagates:
Node A: item_stock = 15
Node B: item_stock = 15
Node C: item_stock = 10
Eventually, all nodes reach the same value:
Node A: item_stock = 15
Node B: item_stock = 15
Node C: item_stock = 15
Key Characteristics
- Temporary inconsistencies are allowed
- Data will converge across replicas over time
- Reads may return stale data during convergence
- Prioritizes availability and partition tolerance over strict consistency
When to Use Eventual Consistency
Eventual consistency is ideal when:
| Situation | Why It Helps |
|---|---|
| High-throughput, low-latency systems | Avoids the overhead of strict consistency |
| Geo-distributed deployments | Tolerates network delays and partitions |
| Systems with frequent writes | Enables faster response without locking or blocking |
| Availability is more critical than accuracy | Keeps services running even during network issues |