Eventual consistency

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (January 2017) (Learn how and when to remove this message)

Eventual consistency is a consistency model used in distributed computing to achieve high availability. Put simply: if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.^[1] Eventual consistency, also called optimistic replication,^[2] is widely deployed in distributed systems and has origins in early mobile computing projects.^[3] A system that has achieved eventual consistency is often said to have converged, or achieved replica convergence.^[4] Eventual consistency is a weak guarantee – most stronger models, like linearizability, are trivially eventually consistent.

Eventually-consistent services are often classified as providing BASE semantics (basically-available, soft-state, eventual consistency), in contrast to traditional ACID (atomicity, consistency, isolation, durability).^[5][6] In chemistry, a base is the opposite of an acid, which helps in remembering the acronym.^[7] According to the same resource, these are the rough definitions of each term in BASE:

• Basically available: reading and writing operations are available as much as possible (using all nodes of a database cluster), but might not be consistent (the write might not persist after conflicts are reconciled, and the read might not get the latest write)
• Soft-state: without consistency guarantees, after some amount of time, we only have some probability of knowing the state, since it might not yet have converged
• Eventually consistent: If we execute some writes and then the system functions long enough, we can know the state of the data; any further reads of that data item will return the same value

Eventual consistency faces criticism^[8] for adding complexity to distributed software applications. This complexity arises because eventual consistency provides only a liveness guarantee (ensuring reads eventually return the same value) without safety guarantees—allowing any intermediate value before convergence. Application developers find this challenging because it differs from single-threaded programming, where variables reliably return their assigned values immediately. With weak consistency guarantees, developers must carefully consider these limitations, as incorrect assumptions about consistency levels can lead to subtle bugs that only surface during network failures or high concurrency.^[9]