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