In an eventually consistent system, if writes stop, all replicas eventually return the same value. Between writes, replicas may diverge.
Eventual consistency trades correctness guarantees for availability and performance. Used well, it powers high-scale systems. Used poorly, it leads to subtle bugs.
Eventual consistency does NOT mean:
It means: if you stop writing, eventually replicas will agree.
In practice, "eventually" might be milliseconds, seconds, or longer. Depends on the system.
CAP theorem: choose two of consistency, availability, partition tolerance.
Distributed systems must tolerate partitions. So choose availability or consistency.
Eventually consistent systems choose A: stay available during partitions, reconcile after.
Strongly consistent systems choose C: become unavailable rather than diverge.
Both have valid use cases.
Strong → weak:
Strongest. Operations appear to take effect at a single instant between invocation and completion.
If client A writes X=1, then client B reads X, B sees X=1.
Operations appear in some sequential order, consistent with each client's order.
Less strict than linearizability (no real-time bounds).
Operations causally related are seen in same order; concurrent operations may differ.
If A writes X then writes Y, all replicas see X before Y. But concurrent A's-X and B's-Z can be ordered differently.
A client always sees its own writes.
Once a client reads value V, it never sees an earlier version.
Replicas converge if writes stop. No order or timing guarantees.
Often combined with eventual consistency:
Within a session, see your own writes.
Within session, never go backward.
Within session, your writes apply in order.
Writes after reads happen after the reads.
These improve UX without strong consistency.
One master accepts writes; slaves replicate asynchronously.
Reads from slaves are eventually consistent.
Multiple nodes accept writes. Conflict resolution required:
R + W > N: linearizable R + W ≤ N: eventually consistent
Tunable consistency in DynamoDB, Cassandra, Riak.
Replicas exchange states periodically; resolve differences.
Background sync ensures convergence.
Information spreads through random pairwise exchanges. Used for membership, state propagation.
User updates profile, then reads it. May see old version.
UX nightmare without read-your-writes.
Two writers update concurrently; one overwrites the other.
Not visible until much later.
Different users see different states. Tickets show "available" to one, "sold out" to another.
Events appear in different orders across replicas. Causally related events may invert.
In a system with many replicas, stale reads are common in normal operation.
Some operations are naturally eventually consistent: counters of likes, caches, search indices.
For operations needing stronger guarantees:
Operations that can be replayed safely. Critical for retry safety.
Detect inconsistency post-hoc; reconcile. Common in financial systems.
Eventually consistent with TTLs. Updates take time to propagate.
Works because DNS doesn't need strong consistency.
Tunable consistency. Operators choose R/W/N values.
Eventually consistent reads by default; strongly consistent reads optional (more expensive).
Replica sets with primary-replica replication. Reads can be tuned.
Eventually consistent originally; now strong read-after-write for new objects.
Distributed version control. Each clone is a replica. Merge required to reconcile.
Cache propagation. Content updates take time to spread.
Indices are eventually consistent with the source. Recent changes don't appear immediately.
Logs, events, immutable data. No update conflicts.
If precision isn't critical (likes, views).
Stale acceptable; refresh periodically.
Slight delay in indexing acceptable.
Message ordering may be relaxed.
Reading from replica acceptable; replica may be slightly stale.
Financial transactions need strong consistency for balances.
Selling more than you have is a real problem.
User logged in / not logged in must be consistent.
Distributed locks, leader election require consensus.
Wrong config values cause real problems.
Building application as if reads are immediately consistent. Bugs appear at scale.
Library or framework behavior not understood. Surprises in production.
User experience suffers without read-your-writes.
Last-write-wins is simple but loses data.
Replication lag is a key metric. Without monitoring, problems compound.
Some operations need strong; others tolerate eventual. Mix appropriately.
How far behind are replicas? Spike means trouble.
Inject delays in test environment. Verify application handles staleness.
Distinguish "missing" from "stale" in logs and dashboards.
Inconsistent state may mean inconsistent backups.
For application developers:
For architects: