Encyclopedia of Database Systems

Living Edition
| Editors: Ling Liu, M. Tamer Özsu

Eventual Consistency

  • Marc ShapiroEmail author
  • Bettina Kemme
Living reference work entry

Later version available View entry history

DOI: https://doi.org/10.1007/978-1-4899-7993-3_1366-2


Conflict Resolution Eventual Consistency Consistency Level Client Request Logical Object 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.



In a replicated database, the consistency level defines whether and how the values of the replicas of a logical object may diverge in the presence of updates. Eventual consistency is the weakest consistency level that guarantees convergence. Informally, it requires that all replicas of an object will eventually reach the same final value, assuming that no new updates are submitted to the object.

Formal Definition and Usage

Eventual consistency is an important correctness criteria in systems with a lazy, update-anywhere strategy, also referred to as optimistic replication. Update operations can be submitted and executed on any node, and the propagation of updates occurs lazily after they are committed. Conflict resolution and reconciliation must ensure that all replicas (copies) of a logical object eventually converge to the same value. Different objects are considered independent. Especially in wide-area settings, also referred to as geo-replication, and mobile computing environments, eventual consistency is popular, as it allows individual replicas to serve client requests and provide a response before coordinating with other replicas. Conflict-free replicated data types (CRDTs) were invented to encapsulate and hide the complexity of managing eventual consistency.

In a system where updates are continuously submitted, eventual consistency can be defined by a weak form of schedule equivalence [1]. A schedule S n x describes the sequence of update operations node n performs on its replica of object x. An element of the schedule of the form w i represents the execution of an update to object x, submitted by some user. S n x contains an element of the form \(\overline{w_{i}}\), if the update w i was received by n, but either not executed, or aborted due to conflict resolution.

Typically, two schedules are defined equivalent by restricting how the order of operations in the two schedules may differ. However, for eventual consistency, only the final convergence of object values matters. Thus, equivalence is defined by comparing the final state of the replicas. Two schedules are said state equivalent when, starting from the same initial state, they produce the same final state. For instance, (i) schedules S = w 1 w 2 and S  = w 2 w 1 are state equivalent if w 1 and w 2 commute; (ii) schedules S = w 1 w 2 and S  = w 2 are state equivalent if w 2 overwrites the state of the object to a completely new value (e.g., x: = 2).

Eventual consistency of a replicated object x is defined by the following conditions, which must hold at all times, at any node n with a replica of x [1]. It is assumed that all replicas have the same initial state:
  • There is a prefix of the schedule S n x that is state equivalent to a prefix of the schedule \(S_{n^{{\prime}}}^{x}\) of any other node n holding a replica of x. Such a prefix is called a committed prefix of S n x .

  • The committed prefix of S n x grows monotonically over time, i.e., the set of operations and their relative order remain unchanged.

  • For every operation w i submitted by a user, either w i or \(\overline{w_{i}}\) eventually appears in the committed prefix of S n x (but not both and not more than once).

  • An operation of the form w i in the committed prefix satisfies all its preconditions (e.g., the state of the object immediately before the execution of the operation fulfills certain conditions).

As an example, assume operation w 1 sets x to 2, and w 2 sets it to 5. Operation w 1 is submitted and executed at n 1 while w 2 is first executed at n 2. At this time, the local schedules are S 1 =  w 1 and S 2 = w 2 and the committed prefix at both nodes is the empty schedule. Now w 1 is propagated to n 2, and w 2 is propagated to n 1. When n 1 receives w 2, it detects that w 1 and w 2 are concurrent and conflict. Say that conflict reconciliation prioritizes one of the operations, e.g., w 1. Then, w 2 is simply not executed and the new schedule is \(S_{1}^{x} = w_{1}\overline{w_{2}}\). At n 2, when w 1 arrives, the conflict is also detected, w 2 is undone, w 1 is executed and the final schedule is \(S_{2} = \overline{w_{2}}w_{1}\). At this time, S 1 and S 2 are themselves the committed prefixes. Note that further concurrent operations on x might move the schedules further, but the extensions would still be tentative and only become committed once they are reconciled at all replicas.


Recommended Reading

  1. 1.
    Saito Y, Shapiro M. Optimistic replication. ACM Comput Surv. 2005;37(1):42–81.CrossRefzbMATHGoogle Scholar
  2. 2.
    Vogels W. Eventually consistent. ACM Queue. 2008;6(6):14–19.CrossRefGoogle Scholar
  3. 3.
    Terry D. Replicated data consistency explained through baseball. Commun ACM. 2013;56(12):82–89.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media LLC 2017

Authors and Affiliations

  1. 1.UPMC-LIP6 & INRIA ParisParisFrance
  2. 2.School of Computer Science, McGill UniversityMontrealCanada

Section editors and affiliations

  • Bettina Kemme
    • 1
  1. 1.School of Computer ScienceMcGill UniversityMontrealCanada