A consistency model defines how a distributed system orders operations and when updates become visible across replicated copies. Replication therefore requires a choice between latency, consistency, and availability: stale reads may be acceptable for faster responses, while applications needing the latest data may accept slower reads. section 4.3
Common models occupy different points between strict global ordering and weak visibility guarantees:
- Linearizability provides the strongest ordering, while eventual consistency provides the weakest; causal and session consistency occupy intermediate positions. section 4.3.3
- Causal consistency preserves the order of causally dependent operations but makes no ordering promise for concurrent operations. Vector clocks can track these causal relationships. section 4.3.3
- Session consistency provides monotonic reads and read-your-writes within one user session, without requiring immediate visibility to other users. section 4.3.3
Collaborative document editing
If user A writes “Hello” and user B observes it before writing “world,” causal consistency ensures other users observe “Hello” before “world.” A concurrent “Goodbye” update may appear before or after that dependent sequence. section 4.3.3
Figure 8.2 Example use of acquire and release memory barriers to ensure the ordering between writes to two variables, data and flag, where it’s critical that the write to data is visible when the write to flag becomes visible. In this example specifically, the flag indicates that some operation is done, where the result of the operation is stored in data. If we allow the write to flag to be visible before the write to data, the process could read invalid or stale data from data.
Acquire and release barriers preserve visibility ordering between related writes, such as publishing data before setting a completion flag. This connects consistency guarantees to shared-memory implementation. section 8.4.1
