Stackbook Logo
data-consistencyestablished · medium operational burden

Eventual Consistency

Also known as: eventually-consistent, convergent-replication

Intent

Accept temporary divergence between replicas in exchange for availability and low latency, guaranteeing convergence once updates stop.

Problem

Synchronous coordination across replicas or services hurts latency and availability. Many workloads do not need every reader to see every write instantly.

Forces

  • •Coordination across regions is slow and fragile
  • •Reads far outnumber writes in many systems
  • •Users tolerate brief staleness for some data
  • •Divergent replicas must still converge

Solution

Overview

Eventual consistency promises that if no new updates are made, all replicas will eventually return the same value. It gives up immediate agreement to gain availability and speed. Amazon's Dynamo paper and Werner Vogels' essay made it a mainstream design choice for large systems.

In practice the window of inconsistency is often milliseconds to seconds, but under backlog or partition it can stretch much longer, which is why it must be monitored rather than assumed.

How it works

A write lands on one or a few replicas and is propagated in the background.

t0  client writes x=2 -> replica A (ack)
t1  replica B still has x=1   (stale read possible)
t2  A replicates to B, C       (async, gossip or log)
t3  all replicas x=2           (converged)

If two replicas accept different writes concurrently, a resolution rule decides the winner: last-write-wins, version vectors with application merge, or CRDTs. Background anti-entropy compares replicas (often using Merkle trees) and repairs drift. Quorum settings can tighten the guarantee where needed.

Pitfalls

  • Equating eventual with random. Good systems bound lag and monitor it.
  • Using last-write-wins on data where silent loss is unacceptable.
  • Forgetting read-your-writes. Users editing a profile and seeing the old value will file bugs.
  • Ignoring deletes; without tombstones, deleted data can reappear after repair.
  • Building workflows that need atomic multi-key updates on top of per-key convergence.

Key takeaways

  • Convergence is guaranteed; timing and ordering are not.
  • Pair it with a defined conflict-resolution strategy.
  • Add session guarantees for user-facing flows.
  • Measure replication lag and treat it as an SLO.

✓ When to Use

  • •Global, high-availability read-heavy workloads
  • •Caches, feeds, counters, and search indexes
  • •Cross-service data propagation through events

✗ When Not to Use

  • •Invariants such as balances or uniqueness that require immediate agreement
  • •Check-then-act logic across replicas
  • •When no conflict-resolution or repair mechanism exists

Pros

  • +High availability and low write latency
  • +Scales across regions
  • +Tolerates partitions gracefully

Cons

  • −Clients can see stale or reordered data
  • −Concurrent writes need conflict resolution
  • −Harder to test and reason about

Cost Profile

Infrastructure

Low: fewer coordination resources

Operational

Medium: monitor lag and repair

Cognitive

High: developers must reason about anomalies

Failure Modes

  • Unbounded replication lag during backlog or partition

  • Lost updates from naive last-write-wins

  • Users see their own writes disappear temporarily

Real-World Examples

Alternatives

  • consistency-model-selection

Related Patterns

  • consistency-model
  • conflict-resolution
  • crdts
  • read-your-writes
  • anti-entropy-merkle-trees
  • gossip-protocol
  • reconciliation-job

Competency Domains

data statedistribution communication