Eventual Consistency vs Strong Consistency Explained
When you read data from a distributed system, how sure are you that the data is up to date? The answer depends on the consistency model. This article compares strong consistency and eventual consistency — the two most common models in distributed databases.
Key sources: "Designing Data-Intensive Applications" by Martin Kleppmann, DynamoDB documentation, Jepsen consistency analysis by Kyle Kingsbury.
The Core Trade-Off
Strong consistency guarantees that every read returns the most recent write. Eventual consistency guarantees that reads will eventually return the most recent write, but may return stale data in the meantime.
This is the fundamental trade-off of the CAP theorem: you can have immediate correctness or high availability, but not both during a network partition.
Strong Consistency (Linearizability)
Definition: After a write completes, all subsequent reads (from any node) return that write. The system behaves as if there is a single, up-to-date copy of the data.
How it works: Before acknowledging a write, the system synchronizes the write across enough replicas to guarantee that future reads will see it. This typically requires a consensus protocol (Paxos, Raft) or a primary node that coordinates all writes.
Example — Bank account balance:
Write: Account balance = $100
Read immediately after: Returns $100
Concurrent read from another node: Returns $100
Advantages: - Developers write simpler code — no need to handle stale data - Users see a consistent view of the system - Essential for financial transactions, inventory management, and locking
Disadvantages: - Slower writes (must wait for synchronization) - Reduced availability during network partitions - Higher latency for geographically distributed systems
Real systems: Google Spanner, ZooKeeper, etcd, traditional relational databases (PostgreSQL with synchronous replication)
Eventual Consistency
Definition: If no new writes are made to a data item, all replicas will eventually converge to the same value. However, reads may return stale data in the interim.
How it works: Writes are accepted by any node and propagated asynchronously to other nodes. No node waits for others to confirm. Conflicts are resolved later using strategies like last-writer-wins, version vectors, or CRDTs.
Example — Social media like count:
Write: Like count = 101
Read from a different node a few seconds later: Returns 100 (stale)
Read from the same node a few seconds later: Returns 101
Read from any node a minute later: Returns 101 (converged)
Advantages: - Fast writes (no synchronization required) - High availability (any node accepts writes at any time) - Excellent for geographically distributed systems - Scales horizontally with ease
Disadvantages: - Temporary inconsistency — users may see stale data - Complex conflict resolution - Harder to reason about application correctness
Real systems: Amazon DynamoDB (default), Cassandra, CouchDB, DNS, Riak
When to Use Each Model
Use Strong Consistency When:
- Financial transactions: Money transfers must be accurate
- Inventory management: Two customers should not buy the same last item
- Unique constraints: Username uniqueness, email uniqueness
- Distributed locking: Coordinating access to shared resources
- Configuration data: Service discovery, feature flags, access control
Use Eventual Consistency When:
- Social media feeds: A slight delay in post visibility is acceptable
- Product catalogs: Price changes that take seconds to propagate
- Analytics and metrics: Aggregate counts that do not need real-time precision
- Content delivery: CDN caches that serve slightly stale content
- Session data: Temporary inconsistencies resolve quickly
The Spectrum of Consistency
Consistency is not binary. Several models exist between strong and eventual:
| Model | Guarantee | Latency | |-------|-----------|---------| | Strong (Linearizability) | All reads see the latest write | Highest | | Read-after-write | A user sees their own writes immediately | High | | Monotonic reads | Reads never go back in time | Medium | | Bounded staleness | Reads return data at most N seconds stale | Configurable | | Eventual | Reads eventually converge | Lowest |
Many databases offer configurable consistency. DynamoDB lets you choose "strongly consistent reads" (higher latency, latest data) or "eventually consistent reads" (lower latency, potentially stale data) on a per-request basis.
Key Takeaways
- Strong consistency guarantees immediate correctness at the cost of latency and availability.
- Eventual consistency prioritizes speed and availability at the cost of temporary inconsistency.
- The choice depends on whether stale data is acceptable for your use case.
- Network partitions force a choice between consistency and availability.
- Many databases offer tunable consistency so you can choose per-operation.
Design principle: Default to strong consistency for correctness-critical operations. Use eventual consistency when availability and latency matter more than real-time accuracy.