What is eventual consistency?

Werner Vogels of Amazon gave a widely used definition. Eventual consistency is a specific form of weak consistency: the storage system guarantees that if no new updates are made to an object, eventually all accesses will return the last updated value.

The period between an update and the moment every reader is guaranteed to see it is called the inconsistency window. While it is open, two people asking two different copies the same question can get different answers. Vogels names DNS as the most popular system that works this way. A change to a name spreads through caches that expire on a timer, and in the end every client sees it.

For an offline app, every device is a copy. A phone that edits its local data on a train, with no signal, is a replica that has moved ahead of the others. Eventual consistency is the promise that once it reconnects and changes stop flowing, every copy will agree.

The reason is availability. Vogels summarises the CAP theorem: of data consistency, availability, and tolerance to network partitions, a shared-data system can only have two at once. In large distributed systems partitions happen anyway, so the real choice is between staying available and staying consistent.

Amazon’s Dynamo paper describes the trade from the other side. Its shopping cart had to accept “add to cart” even while disks failed or network routes flapped, so Dynamo was designed as an eventually consistent store, where all updates reach all replicas eventually.

Offline apps make the same choice for a simpler reason. When there is no connection at all, the only way to keep working is to accept the write locally and reconcile later.

Eventual consistency is a weak promise, and the gaps matter in practice.

• No time limit. Nothing in the definition says how long the window lasts. Vogels notes that, without failures, its maximum size depends on communication delays, system load, and the number of replicas.
• No rule for conflicts. If two copies change the same value, the guarantee says they will end up equal, not which value they will equal. Some systems keep the newest write, as in last writer wins. Dynamo kept conflicting versions and asked the application to merge them, which meant an added item was never lost but a deleted item could reappear.
• No business rules. Shapiro and colleagues define a conflict as concurrent updates that are each correct but together break an invariant. Two technicians each claiming the last spare part while offline is one example. Copies can agree perfectly on a state that is wrong for the business.

Production systems show these edges plainly. In DynamoDB global tables, a write made in one Region is copied to the others asynchronously, and conflicting writes resolve by the latest internal timestamp per item. The documentation warns that a strongly consistent read can still return stale data if the item was last updated in a different Region.

Shapiro, Preguiça, Baquero, and Zawirski observed in 2011 that several eventually consistent systems apply an update immediately, discover later that it conflicts with another, and roll back. That wastes work and in general requires consensus, so that every replica arbitrates the conflict the same way.

They proposed a stronger condition, strong eventual consistency. Replicas that have received the same updates have equivalent state, straight away, with no rollback and no coordination. Data types that meet this condition are called conflict-free replicated data types, or CRDTs. The paper describes counters, sets, and graphs built this way.

For offline apps this is the useful version. Two phones that have exchanged the same changes show the same data, whichever order the changes arrived in, and neither needs a server to decide.

Plain eventual consistency can feel strange to the person holding the device. Vogels lists variations that tighten what one client sees:

• Read-your-writes. After a process updates an item, it always sees the update, never an older value.
• Monotonic reads. Once a process has seen a value, it never sees an earlier one.
• Causal consistency. If one process tells another about an update, the second sees that update and not the earlier value.
• Session consistency. Read-your-writes holds for as long as a session lasts.

Vogels calls monotonic reads and read-your-writes the most desirable in practice. An offline-first app gets read-your-writes on each device naturally, because it writes to its local copy first and reads from it.

A few habits make eventual consistency workable in an app:

• Show whether data has synced, so people know when they might be looking at an old copy.
• Store data in shapes that merge cleanly, such as separate fields instead of one large block, counters instead of totals, and text types for shared notes.
• Send anything that must hold across everyone, such as stock limits or exclusive bookings, to an authority that can reject one of two conflicting actions. How are sync conflicts resolved? covers the options.
• Test with a real partition. Edit on two disconnected devices, reconnect, and check that both copies end up the same.