Cloud Architecture Patterns

Chapter 5. Eventual Consistency Primer

The Eventual Consistency primer introduces eventual consistency and explains some ways to use it. This primer uses the CAP Theorem to highlight the challenges of maintaining data consistency across a distributed system and explains how eventual consistency can be a viable alternative.

In an eventually consistent database, simultaneous requests for the same data value can return different values. This condition is temporary, as the values become “eventually” consistent.

Eventual consistency stems from a choice in the way data is updated. It is an alternative to the use of distributed transactions. It can lead to better scalability, higher performance, and lower cost. Using it or not is a business decision.

At any moment, most of an eventually consistent database is consistent, with some small number of values still being updated. It is common for data values to be inconsistent for only seconds, but is not required. It depends on the application and can vary depending upon current circumstances.

CAP Theorem and Eventual Consistency

Brewer’s CAP Theorem (or simply the CAP Theorem) considers three possible guarantees for data within a distributed application: Consistency, Availability, and Partition Tolerance (which spell CAPT, though the more pronounceable CAP is used). Consistency means everyone gets the same answer; availability means clients have ongoing access (even if there is partial system failure); and partition tolerance means correct operation, ...