that are slightly out of date are okay.
For example, a fan inquiring about
the total number of runs scored by his
team this season, as shown in Figure 9,
can perform an eventual consistency
read to get a reasonable answer.
Clearly, storing baseball scores is not
the killer application for cloud storage
systems. And we should be cautious
about drawing conclusions from one
simple example. But perhaps some lessons can be learned.
Table 4 summarizes the consistency guarantees desired by the variety
of baseball participants that were discussed in the previous section. Recall
that the listed consistencies are not
the only acceptable ones. In particular,
each participant would be okay with
strong consistency, but, by relaxing the
consistency requested for his reads, he
will likely observe better performance
and availability. Additionally, the storage system may be able to better balance the read workload across servers
since it has more flexibility in selecting servers to answer weak consistency
These participants can be thought
of as different applications that are
accessing shared data: the baseball
score. In some cases, such as for the
scorekeeper and sportswriter, the
reader, based on application-specific knowledge, knows he can obtain
strongly consistent data even when
issuing a weakly consistent read using a read my writes or bounded staleness guarantee. In some cases, such
as the radio reporter, multiple guarantees must be combined to meet the
reader’s needs. In other cases, such
as the statistician, different guarantees are desired for reads to different
I draw four main conclusions from
˲ All of the six presented consistency
guarantees are useful. Observe that
each guarantee appears at least once in
Table 4. Systems that offer only eventual consistency would fail to meet the
needs of all but one of these clients,
and systems that offer only strong consistency may underperform in all but
˲ Different clients may want differ-
ent consistencies even when accessing
the same data. Often, systems bind a
specific consistency to a particular da-
taset or class of data. For example, it is
generally assumed that bank data must
be strongly consistent while shopping
cart data needs only eventually con-
sistency. The baseball example shows
that the desired consistency depends
as much on who is reading the data as
on the type of data.
˲ Even simple databases may have
diverse users with different consistency needs. A baseball score is one
of the simplest databases imaginable,
consisting of only two numbers. Nevertheless, it effectively illustrates the
value of different consistency options.
˲ Clients should be able to choose
their desired consistency. The system
cannot possibly predict or determine
the consistency that is required by a
given application or client. The preferred consistency often depends on
how the data is being used. Moreover,
knowledge of who writes data or when
data was last written can sometimes
allow clients to perform a relaxed
consistency read, and obtain the associated benefits, while reading up-to-date data.
The main argument often expressed
against providing eventual consistency
is that it increases the burden on application developers. This may be true,
but the extra burden need not be excessive. The first step is to define consistency guarantees developers can
understand; observe that the six guarantees presented in Table 1 are each
described in a few words. By having
the storage system perform write operations in a strict order, application
developers can avoid the complication of dealing with update conflicts
from concurrent writes. This leaves
developers with the job of choosing
their desired read consistency. This
choice requires a deep understanding
of the semantics of their application,
but need not alter the basic structure
of the program. None of the code snippets that were provided in the previous
section required any additional lines to
deal specifically with stale data.
Cloud storage systems that offer
only strong consistency make it easy
for developers to write correct pro-
grams but may miss out on the bene-
fits of relaxed consistency. The inher-
ent trade-offs between consistency,
performance, and availability are
tangible and may become more pro-
nounced with the proliferation of geo-
replicated services. This suggests that
cloud storage systems should at least
consider offering a larger choice of
read consistencies. Some cloud pro-
viders already offer two both strongly
consistent and eventually consistent
read operations, but this article shows
their eventual consistency model may
not be ideal for applications. Allowing
cloud storage clients to read from di-
verse replicas with a choice of several
consistency guarantees could benefit
a broad class of applications as well
as lead to better resource utilization
and cost savings.
1. abadi, d. Consistency tradeoffs in modern distributed
database system design. IEEE Computer, (feb. 2012).
2. amazon. amazon dynamodb; http://aws.amazon.
3. anderson, e., li, X., shah, m., tucek, j. and wylie, j.
what consistency does your key-value store actually
provide? In Proceedings of the Usenix Workshop on
Hot Topics in Systems Dependability, (2010).
4. bailis, P., Venkataraman, s., franklin, m., hellerstein,
j. and stoica, I. Probabilistically bounded staleness
for practical partial quorums. In Proceedings VLDB
Endowment, (aug. 2012).
5. brewer. e. CaP twelve years later: how the “rules”
have changed. IEEE Computer, (feb. 2012).
6. Calder, b. et. al. windows azure storage: a highly
available cloud storage service with strong
consistency. In Proceedings ACM Symposium on
Operating Systems Principles, (oct. 2011).
7. Cooper, b., ramakrishnan, r., srivastava, u.,
silberstein, a., bohannon, P., jacobsen, h.a., Puz, n.,
weaver, d. and yerneni, r. Pnuts: yahoo!’s hosted
data serving platform. In Proceedings International
Conference on Very Large Data Bases, (aug. 2008).
8. google. read Consistency & deadlines: more Control
of your datastore. google app engine blob, mar. 2010;
9. kraska, t., hentschel, m., alonso, g. and kossmann,
d. Consistency rationing in the cloud: Pay only when it
matters. In Proceedings International Conference on
Very Large Data Bases, (aug. 2009).
10. saito, y. and shapiro, m. optimistic replication. ACM
Computing Surveys, (mar. 2005).
11. terry, d., demers, a., Petersen, k., spreitzer, m.,
theimer, m., and welch, b. session guarantees for
weakly consistent replicated data. In Proceedings
IEEE International Conference on Parallel and
Distributed Information Systems, (1994).
12. Vogels, w. eventually consistent. Commun. ACM, (jan.
13. wada, h., fekete, a., zhao, l., lee, k. and liu, a.
data consistency properties and the trade-offs
in commercial cloud storages: the consumers’
perspective. In Proceedings CIDR, (jan. 2011).
Doug Terry ( firstname.lastname@example.org) is a Principal
researcher in the microsoft research silicon Valley lab,
mountain View. Ca.
Copyright held by owner/author(s). Publication rights
licensed to aCm. $15.00