Skip to content

13 · Eventual Consistency — Soft-State Distributed Consistency Model

Performance & Distribution · Topic 13 of 13

What is Eventual Consistency?

In a distributed system, eventual consistency guarantees that if no new writes occur, all replicas will converge to the same value over time. There is no guarantee of when, only that it will happen.

Why Accept Weaker Consistency?

Strong consistency requires coordination (locks, consensus) which increases latency and reduces availability. Eventual consistency allows:

  • Lower write latency (write to one node, propagate async)
  • Higher availability during network partitions (AP systems)
  • Geographic distribution without global consensus

Consistency Spectrum

graph LR
    S[Strict / Linearizable] --> E[Sequential] --> C[Causal] --> M[Monotonic Read] --> EV[Eventual]
Model Guarantee Example
Linearizable Global real-time ordering Google Spanner
Causal Cause-before-effect ordering MongoDB causal sessions
Read-your-writes You see your own writes DynamoDB ConsistentRead
Monotonic reads Never reads older snapshot twice Cassandra with tuning
Eventual Only convergence guaranteed Cassandra (ONE), DynamoDB (default)

Conflict Resolution

When two replicas accept conflicting writes during a partition, they must resolve:

Strategy How Used By
Last-Writer-Wins (LWW) Highest timestamp survives Cassandra, DynamoDB Global Tables
Vector Clocks Track causality per node Riak
CRDTs Math-proven merge operations Cassandra counters, Redis sets
Application-level App resolves on read Shopping cart merge (Amazon's Dynamo paper)

Cloud Implementations

  • Default: eventual consistency
  • ConsistencyLevel.ONE — fastest, least consistent
  • Tunable: QUORUM reads + QUORUM writes → strong consistency
  • ConsistentRead: false (default) → eventually consistent, cheaper
  • ConsistentRead: true → strongly consistent (for the local region)
  • Global Tables: always eventually consistent across regions
  • Strongly consistent by default; no eventual mode
  • Stale reads available via bounded staleness for lower latency
  • Secondary reads are eventually consistent
  • Causal consistency via sessions: session.advanceClusterTime()