NOTE
3.5 Distributed Consistency Models
A practical map of linearizability, eventual and causal consistency, read-your-writes, session consistency, monotonic reads and writes, and consistent-prefix reads.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is a Consistency Model?
A consistency model defines which values and orderings clients are allowed to observe when data is replicated across nodes. Different models trade stronger guarantees for different costs in coordination, latency, and availability.
2. Common Consistency Models
Useful models include:
- linearizability;
- eventual consistency;
- causal consistency;
- read-your-writes consistency;
- session consistency;
- monotonic-read consistency;
- monotonic-write consistency;
- consistent-prefix reads.
3. Linearizability
3.1 Definition
Once a write completes successfully, later operations should behave as though that write took effect atomically at a single point in time. A linearizable store can be reasoned about as if there were one copy of the data and operations occurred in a single real-time-consistent order.
3.2 Typical Uses
- distributed locks and leader election;
- uniqueness constraints, such as a globally unique username;
- coordination where multiple communication channels must observe a compatible order.
3.3 Cost
Linearizability usually requires coordination between replicas. Under a network partition, preserving it may require delaying or rejecting operations, which is the availability trade-off described by CAP.
4. Eventual Consistency
Eventual consistency allows replicas to temporarily diverge. If updates stop and communication continues successfully, replicas eventually converge.
The model itself does not define a universal maximum convergence time.
5. Causal Consistency
If operation B causally depends on operation A, every observer should see A before B. Concurrent operations without a causal relationship do not necessarily need a single global order.
5.1 Partial and Total Orders
A total order can compare every pair of operations. A partial order allows some operations to remain incomparable because they are concurrent.
The happens-before relation is a partial order: if A caused B, then A must appear before B.
5.2 Implementation Ideas
Systems can track causal relationships using logical clocks or version metadata. A single leader can also impose an order on operations, while multi-leader or leaderless systems need additional metadata and conflict-handling rules.
6. Read-Your-Writes Consistency
A user who has just completed a write should not immediately read an older value for that same data merely because the read reached a lagging replica.
Possible approaches include:
- temporarily route the user’s own reads to the leader or an up-to-date replica;
- record the logical version of the latest write and only read from a replica that has caught up to at least that version.
7. Session Consistency
Session consistency provides guarantees such as read-your-writes within the scope of a client session.
8. Monotonic Reads
After a client has observed version v2, later reads by that client should not go backward to an older version v1.
One simple implementation is replica affinity: consistently route a user to the same replica, assuming that replica itself does not move backward.
9. Monotonic Writes
Writes from the same client are applied in the order they were issued. This prevents a later write from taking effect before an earlier dependent write.
10. Consistent-Prefix Reads
If a sequence of writes has an established order, a reader should not observe a later write without observing the earlier prefix first. This matters when related writes are processed by different partitions.
A common design goal is to place causally related data in the same partition or propagate enough ordering metadata to preserve the required prefix.