What a read promises
Strong consistency guarantees that once a write commits, every later read sees it. The system behaves as if there is a single copy of the data, even when it is replicated.
Eventual consistency promises only that, if writes stop, all replicas will converge to the same value after some time. In the meantime a read may return a stale value.
Why eventual is attractive
- Replicas can accept writes and serve reads without coordinating on every operation, so they stay available during partitions and respond with low latency.
- This is the natural fit for geo distributed systems where coordinating across regions on every write is too slow.
Why strong is sometimes required
- For a bank balance or a unique username, returning stale data is a correctness bug.
- Strong consistency needs a quorum or a leader, which adds latency and reduces availability during partitions.
Living with eventual consistency
- Read your writes ensures a user sees their own updates even if others lag.
- Conflict resolution, such as last writer wins or merge functions, decides what happens when two replicas diverge.
Pick strong only where correctness demands it and accept eventual elsewhere for speed and availability.
Key idea
Strong consistency makes every read see the latest write at the cost of coordination while eventual consistency lets replicas diverge briefly to gain availability and speed.