practice
IN RECENT YEARS, there has been a lot of excitement
over eventual consistency. 6 Heck, I get pretty excited
about it! Eventual consistency is an aspect of some data
that says its underlying value is unknown until work on
that item settles down. It turns out that, in many cases,
there are data items for which the work never settles
down. In addition to being eventually consistent, many
data items remain consistently eventual!
Eventual consistency occurs when the value for
something is replicated in more than one place, and
there is a protocol for these replicas converging.
Changes to one or more of the replicas can be done
independently, and they will propagate and converge.
Eventual consistency:
When we all know the same stuff, we will have the
same result.
In this article, I do not want to talk about how
eventual consistency can be accomplished but more
about what it looks like when it’s used. Many fun
papers have been written about eventual consistency.
One of my favorites is “Eventual Consistency Today:
Limitations, Extensions, and Beyond,”
by Peter Bailis and Ali Ghodsi. 1
As already mentioned, eventual
consistency is typically used to describe the behavior of a data item that
is replicated over decoupled systems.
When updates happen to disconnected replicas separately, how do they behave when they reconnect and share
their state?
Still, eventual consistency typically
refers to the behavior of a single replicated object. It does not usually speak to
transactions and what they mean with
eventually consistent objects.
Data Floating Loose in
the Mean, Cruel World
Data in a relational database behaves
differently from data kept outside
of one. When nonrelational data is
unlocked, it gets captured as a message, file, key value, or something else
grouped as a lump. These lumps (or
objects, values, or entities) have an
identity and version. 2
Eventual consistency arises when an
object with multiple replicas, each with
the same identity, somehow coalesces to
a common value—even when the different replicas are updated independently.
This inherently means the version(s) of
the object are not linearly assigned. It
no longer makes sense to talk about a
strict ordering of the changes. You must
be prepared to capture the version of
the object in a fashion that represents
independent changes coming together.
An excellent versioning mechanism is
the vector clock.
It is important to recognize that the
entire eventual consistency discussion
must necessarily work in a world with
objects, identities, and versions. It’s
not really a classic database thing.
Wait … What Does
a Transaction Mean?
“Last Writer Wins” is a form of eventual consistency. Consider a system
that captures the wall-clock time
from the local system whenever it updates a replica. When everyone has
heard all the updates, the one written
Consistently
Eventual
DOI: 10.1145/3209277
Article development led by
queue.acm.org
For many data items, the work
never settles on a value.
BY PAT HELLAND
