~80s Visual Explainer

Eventual Consistency

How distributed databases synchronize without blocking writes.

Based on: Eventual Consistency Replication Consensus
US-East EU-West Asia-Pacific R1 x = 3 ✓ R2 x = 3 ✓ R3 x = 3 ✓ All replicas in sync: x = 3 ✓ Fully Consistent US-East EU-West Asia-Pacific C x=5 R1 x = 5 ✓ OK! R2 x = 3 ! R3 x = 3 ! Write accepted locally — R2, R3 now stale ⚡ Fast Write (local) US-East EU-West Asia-Pacific R1 x = 5 sync sync R2 x = 3 ... R3 x = 3 ... ⏱ 50ms - 500ms Background sync in progress... R1 x=5 R2 x=3 R3 x=3 A x = 5 B x = 3 ⚠️ Same data, different values! t₀ now t₁ Inconsistency Window Clients see different values during sync US-East EU-West Asia-Pacific R1 x = 5 ✓ R2 x = 5 ✓ R3 x = 5 ✓ ✓ All Replicas Converged System eventually consistent: x = 5 everywhere
1 / ?

Three Replicas in Sync

In a distributed database, data is replicated across multiple nodes — often in different geographic regions. At this moment, all three replicas have the same value: x = 3.

This is the ideal state: complete consistency across all nodes. But maintaining this state during writes requires coordination.

  • Replicas provide fault tolerance and lower latency
  • Consistency means all replicas have identical data
  • Strong consistency requires coordination on every write

Write Accepted Locally

A client in the US writes x = 5. Instead of coordinating with all replicas before responding, the local replica (R1) accepts the write immediately and returns success.

This is the key trade-off: fast writes in exchange for temporary inconsistency. The client doesn't wait for global agreement.

  • Write latency = single node latency (fast!)
  • Local replica is immediately consistent
  • Remote replicas are now stale
  • Client receives success before full propagation

Background Synchronization

The update propagates to other replicas asynchronously — in the background, without blocking the original write. This might take milliseconds or seconds depending on network conditions.

Different systems use different mechanisms: gossip protocols, anti-entropy processes, or explicit replication streams.

  • Propagation happens after client response
  • Network latency determines sync speed
  • No blocking means high availability
  • Systems use various sync strategies

The Inconsistency Window

During propagation, a read anomaly can occur. Client A reads from R1 and sees x = 5. Client B reads from R2 and sees x = 3. Same data, different values.

This is the "eventual" in eventual consistency. The system is inconsistent right now, but promises to converge.

  • Window duration varies (ms to seconds)
  • Different clients may see different values
  • Application must tolerate this behavior
  • Not suitable for all use cases (e.g., bank balances)

All Replicas Converge

Once propagation completes, all replicas have the same value. The system is consistent again — until the next write.

"Eventually" has no time bound. It could be 50ms or 5 minutes. The guarantee is convergence, not timing.

  • All replicas eventually agree
  • No guarantee on convergence time
  • Conflict resolution needed for concurrent writes
  • Trade-off: availability over immediate consistency

What's Next?

Eventual consistency is one end of the consistency spectrum. Understanding when to use it versus strong consistency is crucial for designing distributed systems that meet your requirements.