replicas have acknowledged the write, thus allowing the write to survive W- 1 replica failures. Anti-entropy can be run as often or as rarely as desired without violating any guarantees. What’s not to like?

Safety and liveness. While eventual consistency is easy to achieve, the current definition leaves some unfortunate holes. First, what is the eventual state of the database? A database always returning the value 42 is eventually consistent, even if 42 were never written. Amazon CTO Werner Vogels’ preferred definition specifies that “eventually all accesses return the last updated value;” accordingly, the database cannot converge to an arbitrary value. 23 Even this new definition has another problem: what values can be returned before the eventual state of the database is reached? If replicas have not yet converged, what guarantees can be made on the data returned?

These questions stem from two kinds of properties possessed by all distributed systems: safety and liveness. 2 A safety property guarantees that “nothing bad happens;” for example, every value that is read was, at some point in time, written to the database. A liveness property guarantees that “something good eventually happens;” for example, all requests eventually receive a response.

The difficulty with eventual consistency is that it makes no safety guarantees—eventual consistency is purely a liveness property. Something good eventually happens—the replicas agree—but there are no guarantees with respect to what happens, and no behavior is ruled out in the meantime! For meaningful guarantees, safety and liveness properties need to be taken together: without one or the other, you can have trivial implementations that provide less-than-satisfactory results.

Virtually every other model that is stronger than eventual provides some form of safety guarantees. For almost all production systems, however, eventual consistency should be considered a bare-minimum requirement for data consistency. A system that does not guarantee replica convergence is remarkably difficult to reason about.

the difficulty
with eventual
consistency is
that it makes no
safety guarantees—
eventual
consistency
is purely a liveness
property.

how eventual is
eventual Consistency?

Despite the lack of safety guarantees, eventually consistent data stores are widely deployed. Why? While eventually consistent stores do not promise safety, there is evidence that eventual consistency works well in practice. Eventual consistency is “good enough,” given its latency and availability benefits. For the many stores that offer a choice between eventual consistency and stronger consistency models, scores of practitioners advocate eventual consistency.

The behavior of eventually consistent stores can be quantified. Just because eventual consistency does not promise safety does not mean safety is not often provided—and you can both measure and predict these properties of eventually consistent systems using a range of techniques that have been recently developed and are making their way to production stores. These techniques—which we discuss next— have surprisingly shown that eventual consistency often behaves like strong consistency in production stores.

Metrics and mechanisms. One common metric for eventual consistency is time: how long will it take for writes to become visible to readers? This captures the “window of consistency” measured according to the wall clock. Another metric is versions: how many versions old will a given read be? This information can be used to ensure readers never go back in time and observe progressively newer versions of the database. While time and versions are perhaps the most intuitive metrics, there are a range of others, such as numerical drift from the “true” value of each data item and combinations of each of these metrics. 25

The two main kinds of mechanisms for quantifying for eventual consistency are measurement and prediction. Measurement answers the question, “How consistent is my store under my given workload right now?” 18 while prediction answers the question, “How consistent will my store be under a given configuration and workload?” 4 Measurement is useful for runtime monitoring and alerts or verifying compliance with ser-vice-level objectives (SLOs). Prediction is useful for probabilistic what-if analyses such as the effect of configuration