Eventual Consistency

In Turkish: Nihai Tutarlılık

Updated September 30, 20263 min read

In short

Eventual consistency is a guarantee that, if no new updates are made, all copies of a piece of data in a distributed system will become identical over time.

What is eventual consistency?

Eventual consistency is a consistency model used by systems that keep several copies, or replicas, of the same data on different servers. Right after a write, some replicas may still return the old value, but once updates stop, all replicas converge on the same value. The model does not promise how long this takes, although in practice it is usually milliseconds to seconds.

In an eventually consistent system, a write is accepted by one or a few replicas and acknowledged quickly, and the change spreads to the other replicas in the background. If two replicas accept conflicting writes at the same time, the system resolves the conflict with a rule such as last writer wins, version vectors, or special conflict-free replicated data types (CRDTs). Background processes such as read repair and anti-entropy sync bring lagging replicas up to date, and some databases let each request choose how many replicas must respond, trading speed for fresher reads.

Eventual consistency is like news spreading through a town: when a shop changes its opening hours, some people know right away and others hear later, but eventually everyone has the new hours. DNS, CDN caches, social media like counters, shopping carts, many NoSQL databases, and read replicas of relational databases all behave this way. Systems choose it because it keeps them fast and available even when parts of the network fail, a trade-off described by the CAP theorem.

Eventual consistency is often contrasted with ACID, but they describe different things. The C in ACID means a transaction keeps data valid according to the database's rules, and ACID isolation controls what concurrent transactions see, usually on one database. Eventual consistency is about how quickly replicas agree; its opposite is strong consistency, where every read returns the latest write. Eventual consistency also doesn't mean data is lost or random, only that reads can be briefly stale.

Key takeaways

Replicas may briefly disagree, but they converge once updates stop.
Writes are acknowledged quickly and propagated to other replicas in the background.
Conflicting writes are resolved with rules such as last writer wins or CRDTs.
It favors availability and speed, a trade-off explained by the CAP theorem.
It differs from strong consistency, where every read sees the latest write.

Example

A stale read from a replicajavascript

// The write goes to the primary database
await primary.query("UPDATE users SET name = 'Ada' WHERE id = 1");

// A read from a replica a moment later may still return the old name
const maybeStale = await replica.query("SELECT name FROM users WHERE id = 1");

// Read-your-own-writes: after a write, read from the primary
// (or wait until the replica has caught up) when freshness matters
const fresh = await primary.query("SELECT name FROM users WHERE id = 1");

Readers ask

How long does eventual consistency take?

There is no fixed limit in the definition. In healthy systems replicas usually agree within milliseconds or a few seconds, but network problems or overloaded servers can stretch that out.

What is the difference between eventual consistency and strong consistency?

With strong consistency, every read returns the most recent write, as if there were only one copy of the data. With eventual consistency, a read may return an older value for a short time, which lets the system stay faster and more available.

Is eventual consistency the opposite of ACID?

Not exactly. ACID describes guarantees for transactions, while eventual consistency describes how replicas agree over time. Eventually consistent systems are often described with the looser BASE model: basically available, soft state, eventually consistent.