In this lesson, you will learn how to implement session, monotonic read, and causal consistency to provide a predictable user experience within geographically dispersed database clusters.
When working with geo-distributed systems, we often trade off strong global consistency for availability. However, users experience "flickering" data when they read from different replicas that haven't synchronized yet. To solve this, we implement client-centric consistency models.
Monotonic Read Consistency
This model ensures that if a process reads the value of a data item, any successive read by that process will always return that same value or a more recent one. In a geo-distributed setup, we achieve this by sticky sessions or by attaching a version_timestamp to the client's request. If the replica the client reaches has a lower version than the client's last seen timestamp, the system forces a sync or redirects the client to an up-to-date node.
Session Consistency
This is a common implementation of monotonic reads restricted to a single user session. The system guarantees that the client always sees their own writes.
-- Conceptual implementation logic
-- When a user updates their profile in the US region:
UPDATE users SET bio = 'New bio' WHERE id = 101;
-- The system returns a "Latest Write Token" (e.g., LSN 500) to the client.
-- When the user moves to the EU region:
SELECT bio FROM users WHERE id = 101
AND replication_lag_check >= 500;
-- The EU replica must wait until it catches up to LSN 500 before serving.
Causal Consistency
This is the strongest model we will cover. It ensures that operations that are causally related are seen by every node in the same order. If User A replies to User B’s post, causal consistency guarantees that no user will ever see the reply before the original post, regardless of geographical latency. This is implemented using vector clocks or dependency tracking, where each write carries metadata about the operations it depends on. Nodes refuse to process an incoming update until all its "parent" dependencies are satisfied.
Key Takeaway: By using metadata tags like version vectors or session tokens, we can provide strong individual user guarantees without incurring the extreme latency penalties of global synchronous consensus.