In database systems, consistency has a tangible interpretation: A transaction transitions the database from one valid state to another valid state, where validity is defined by application-level constraints (ensuring, for example, that an account balance is always non-negative).
In distributed systems, components may fail and messages may be delayed, reordered, or lost; consistency can take on multiple interpretations. In this chapter, we’ll explore several consistency models and discuss common scenarios in which they arise.
9.1 Consistency models
To focus on consistency, in this chapter we reason about a distributed system as a collection of concurrent processes operating on a collection of objects. A process is a sequence of operations on objects. The object’s type defines the set of possible values and the set of possible operations to create and manipulate object instances. An operation is not instantaneous; instead, it is delineated by its invocation and completion. We model an operation on an object as an invocation and completion pair:
Operation = Invocation • Completion
Processes are strictly sequential. That is, each process issues a sequence of operations to objects, alternately issuing an invocation and waiting to receive the associated response (see figure 9.1).