What Is Eventual Consistency? Examples and How Systems Achieve It
Eventual consistency is a guarantee about replicas, the copies of one piece of data kept on different servers. If writes to that data stop, every replica will eventually return the same value. Until that moment, a read may return an older value than the one just written. "Eventually" has no fixed bound. Most systems converge within milliseconds to a few seconds, while DNS can take an hour or more.
Systems accept this because the alternative is expensive. A write that must reach every replica before it is confirmed costs a network round trip per replica. It also fails if any replica is unreachable. An eventually consistent system confirms the write once one replica, or a small number, has it. The rest is done in the background, so writes stay fast and the system keeps answering during a network partition.
Everyday examples
DNS record propagation. When you change a domain's address record, resolvers around the world keep the old record until its TTL runs out. The TTL (time to live) is the number of seconds a cached record stays valid. With a 3,600-second TTL, a resolver that cached the old address a minute ago serves it for another 59 minutes. Two users in different cities can reach different servers for up to an hour.
A like count that differs by region. A social network keeps a copy of a post's counter in each region. Increments are applied locally and shipped to the other regions a moment later. A user in Singapore may see 1,204 likes while a user in Frankfurt sees 1,198. A few seconds later both see the same number.
Shopping carts in Dynamo-style stores. Amazon's Dynamo design accepted writes to a cart on any replica, even during a partition. When two versions of the same cart met, the store merged them by taking the union of their items. An added item was never lost, although a deleted item could reappear.
Object storage across regions. Amazon S3 cross-region replication copies each new object to the second region asynchronously. Most objects arrive within 15 minutes. An object uploaded in one region may therefore not exist yet when read from the other.
How systems achieve it
Read repair. On a read, the coordinator node asks several replicas for the value. If the answers differ, it returns the newest to the client and writes that value back to the replicas that were behind. Cassandra and other Dynamo-style stores do this, so every read of a stale key also fixes it.
Anti-entropy with Merkle trees. Anti-entropy is a background process that compares two replicas and repairs every difference. A Merkle tree is a tree of hashes: each leaf covers a range of keys, and each parent hashes its children. Two replicas compare root hashes and descend only into the subtrees that differ. Cassandra's repair command works this way. A replica holding millions of keys can find a handful of differences by exchanging a few thousand hashes.
Hinted handoff. When a replica is down, another node accepts the write on its behalf and stores a hint. A hint is a record saying which write the absent replica still owes. When the replica returns, the hint is replayed to it. Cassandra keeps hints for 3 hours by default; a replica that is away longer needs a full repair.
Gossip protocols. Each node periodically exchanges what it knows with a few random peers, once per second in Cassandra. Those peers pass it on in the next round. Information about membership, failures, and schema reaches every node in about log2(N) rounds, so about 10 rounds for 1,000 nodes.
Vector clocks and version vectors. A version vector is a list of (replica, counter) pairs attached to each value. Each replica increments its own counter when it writes. Comparing two vectors tells you whether one version descends from the other. If neither does, the two were written at the same time on different replicas, which is a conflict. Riak and the original Dynamo used them to detect such conflicts and hand both versions to the application to merge.
CRDTs. A conflict-free replicated data type is a data structure whose merge rule gives the same result whatever order replicas merge in. A grow-only counter keeps one count per replica and sums them. An add-wins set keeps an item if any replica added it after the last delete. Riak data types and collaborative editors use CRDTs, so replicas converge with no manual conflict resolution at all.
Strong versus eventual, in one paragraph
Strong consistency guarantees that every read returns the latest confirmed write. Systems achieve it by routing all writes through one leader, or by waiting for a quorum, a majority of replicas, before confirming. That adds latency and refuses requests when a majority is unreachable. The two models are compared side by side in What is Strong vs Eventual Consistency?. Why a database must choose during a partition is explained in What is the CAP theorem and what trade-offs does it imply for distributed databases?. The NoSQL model built on this choice is described in What is the BASE consistency model?.
How to talk about it in the interview
Name the data that tolerates it and the data that cannot. Feeds, like counts, view counts, recommendations, search indexes, and notification badges tolerate it. A reader who sees a value a few seconds old loses nothing. Account balances, inventory at checkout, unique usernames, and seat reservations cannot. A stale read there lets two people take the same thing.
Then say the mechanism and the window. "The feed is eventually consistent; replicas converge through read repair and hinted handoff, usually within a second". That sentence shows the interviewer that you chose the model for a reason and know how the system delivers it.
How to Prepare
- Explain each of the six mechanisms in two sentences from memory. Interviewers ask "how does it become consistent" more often than "what does it mean".
- Sort a list of ten data types into tolerates and cannot tolerate, and give the one-line reason for each.
- Give a number for the convergence window whenever you say eventual, such as "under a second inside a region".
- Study the consistency chapters in Grokking System Design Fundamentals, which cover consistency models, quorums, and replication with diagrams.
- Apply the model in full designs with Grokking the System Design Interview, where the feed, the counter, and the checkout each get the model they need.
GET YOUR FREE
Coding Questions Catalog
$99
$197
$72
