Eventual Consistency: Mermaid Flowchart Diagram

About Source

Eventual consistency is a consistency model used in distributed systems that guarantees that, if no new updates are made to a data item, all replicas will eventually converge to the same value — but does not guarantee when.

This diagram shows the state of a distributed system across three nodes after a write is applied to Node A. Immediately after the write, Node A holds the new value v2 while Nodes B and C still hold the stale value v1. A client reading from Node B at this moment will receive the old value — this is called a stale read. As the replication mechanism propagates the change, Node B receives and applies the update, then Node C follows. Once all nodes have applied the update, the system is in a converged state where every node returns v2.

The time window between the initial write and full convergence is the inconsistency window. Its duration depends on replication topology, network latency, node load, and the anti-entropy protocol (gossip, log shipping, CRDTs). Systems like DynamoDB, Cassandra, and Riak are built around eventual consistency, trading strong consistency for high availability and partition tolerance as described by the CAP Theorem Model.

Applications built on eventually consistent stores must tolerate stale reads. Common strategies include read-your-writes consistency (routing a user's reads to the same node that accepted their write), monotonic read consistency (ensuring a client never observes a regression to an older value), and last-write-wins conflict resolution using vector clocks or timestamps.

For developers, the most common encounter with eventual consistency is replication lag in Database Replication setups. An asynchronous replica can be seconds or minutes behind the primary. The Primary Replica Sync diagram shows where that lag originates in the replication protocol.

Frequently asked questions

Eventual consistency is a distributed systems guarantee that if no new updates are made to a data item, all replicas will converge to the same value — but the model makes no promise about how quickly that convergence happens. During the inconsistency window, different nodes may return different values for the same key.

After a write is applied to one node, the replication mechanism propagates the change to other nodes asynchronously. Each recipient node applies the update to its local state. During propagation, reads from nodes that have not yet received the update return stale values. Once all nodes apply the update, the system reaches a converged state where every read returns the same value.

Use eventually consistent databases (Cassandra, DynamoDB, CouchDB) when availability and partition tolerance are higher priorities than read accuracy — social feeds, user activity counters, product catalogue views, recommendation engines, or any feature where a brief stale read is acceptable to users. Avoid eventual consistency for financial balances, inventory counts, or any use case where a stale read could cause incorrect decisions with real-world consequences.

The most common issue is read-your-writes violations: a user writes data and then immediately reads it from a replica that hasn't applied the update yet, making the write appear to have failed. Mitigate by routing post-write reads to the same node or using session-level consistency tokens. Conflict resolution is another challenge when concurrent writes to different nodes diverge — last-write-wins (by timestamp) is simple but can silently discard updates.

mermaid

flowchart TD
    Write[Client writes value v2\nto Node A] --> NodeA[(Node A\nvalue: v2)]

    NodeA -->|Replicate| NodeB[(Node B\nvalue: v1 stale)]
    NodeA -->|Replicate| NodeC[(Node C\nvalue: v1 stale)]

    NodeB --> ReadB{Read from Node B}
    ReadB -->|Before sync| StaleRead[Returns v1 - stale read]
    ReadB -->|After sync| FreshB[Returns v2]

    NodeB -->|Receives update| SyncB[Node B applies v2]
    NodeC -->|Receives update| SyncC[Node C applies v2]

    SyncB --> Converged{All nodes synced?}
    SyncC --> Converged
    Converged -->|Yes| Consistent[Consistent state\nAll nodes return v2]
    Converged -->|No| Wait[Wait for propagation]
    Wait --> Converged