Eventual vs Strong Consistency
Consistency is a core challenge in distributed systems. When data is replicated across multiple nodes, we must decide how quickly updates become visible and what guarantees we can provide to clients.
This article explores the difference between strong consistency and eventual consistency, trade-offs, and real-world use cases.
1. What is Consistency?
In distributed databases and systems, consistency refers to the view of data across replicas.
- Strong consistency → All clients always see the latest committed value.
- Eventual consistency → Clients may see stale data, but replicas converge eventually.
Consistency is at odds with availability and partition tolerance (see CAP Theorem).
2. Strong Consistency
Definition
After a write is acknowledged, all subsequent reads will see the latest value.
Example
- Write
X=5to DB. - Any read after that → returns
5. - Achieved via synchronous replication, quorum reads/writes.
Advantages
- Simple mental model for developers.
- Ensures correctness in financial/critical apps.
- No stale reads.
Disadvantages
- High latency due to coordination (quorum, locks).
- Lower availability during network partitions.
- Expensive in geo-distributed systems.
Use Cases
- Banking & financial transactions.
- Inventory management.
- Leader election in consensus algorithms.
3. Eventual Consistency
Definition
After a write, not all replicas are immediately updated. Over time, replicas will converge to the same state.
Example
- Write
X=5to one replica. - Another client reads from a lagging replica → may still see old value
X=3. - Eventually, replication catches up, all replicas show
5.
Advantages
- High availability (writes succeed locally).
- Low latency.
- Scales well in geo-distributed systems.
Disadvantages
- Clients may observe stale or inconsistent data.
- Developers must handle anomalies (duplicate updates, read-after-write issues).
Use Cases
- Social media feeds.
- Product catalogs.
- DNS systems.
4. Causal & Tunable Consistency (Middle Ground)
Many systems offer tunable consistency:
- Quorum-based reads/writes (N, R, W model):
- N = total replicas, R = read replicas, W = write replicas.
- If R + W > N → strong consistency.
- Else → eventual consistency.
- Causal consistency: ensures cause-effect order (if A happens before B, all clients agree).
Examples: DynamoDB, Cassandra, CosmosDB.
5. Real-World Examples
Strong Consistency:
- Google Spanner (global clock, Paxos).
- ZooKeeper (leader-based consensus).
Eventual Consistency:
- DynamoDB (default mode).
- Cassandra (AP-first).
- DNS (eventual propagation of records).
6. Trade-offs
| Aspect | Strong Consistency | Eventual Consistency |
|---|---|---|
| Latency | Higher (due to coordination) | Lower |
| Availability | Lower (may reject writes) | Higher |
| Complexity | Easier for developers | Harder (must handle anomalies) |
| Scalability | Limited | Excellent |
7. Interview Tips
- When asked: “Which consistency model will you choose?” →
Always clarify use case:- Banking → strong.
- Social media → eventual.
- Bring up CAP theorem: can’t have perfect consistency + availability in a partition.
- Mention tunable consistency as a practical solution.
- Use real-world examples (Spanner, DynamoDB).