Communications of the ACM

APPLICATIONS HAVE HAD an interesting evolution as
they have moved into the distributed and scalable
world. Similarly, storage and its cousin databases have
changed side by side with applications. Many times, the
semantics, performance, and failure models of storage
and applications do a subtle dance as they change in

support of changing business requirements and environmental challenges. Adding scale to the mix has really stirred things up. This article looks at some of these issues and their impact on systems.

Before database transactions, there
were complexities in updating data, es-
pecially if failures happened. This held
true even though the systems were cen-
tralized and avoided the complexities
presented by distribution. Database
transactions dramatically simplified
the life of application developers. It was
great while it lasted …
As solutions scaled beyond a single
database, life got ever more challeng-
ing. First, we tried to make multiple da-
tabases look like one database. Then,
we were hooking multiple applications
together using service-oriented archi-
tecture (SOA). In SOA, each service had
its own discrete database with its own
transactions but used messaging to
coordinate across boundaries. Soon,
we were using microservices, each of
which likely did not have its own data
but reached directly to a distributed
store shared across many separate ser-
vices. This scaled better—if you got the
implementation right.

Different types of distributed stores offer various average speeds, variation in responsiveness, capacity, availability, and durability. Diverse application patterns use the stored data for distinct purposes. They provide various guarantees to their users based largely on their use of storage. These different guarantees from the app sometimes show variations in what the users see in semantics, response time, durability, and more. While these can be surprising, it may be OK. What matters is the