Guarantees for One Client at a Time
System-wide consistency guarantees (like linearizability) are expensive because they require coordination across all nodes for every operation. A practical middle ground is to provide guarantees from the perspective of a single client's session rather than the entire system. These are called session guarantees or client-centric consistency models.
These models are widely implemented in production systems. Amazon DynamoDB, Cassandra, and MongoDB all offer session-level guarantees even when their system-wide model is eventual consistency.
1. Read-Your-Writes (RYW)
This is one of the most practically important session guarantees. It guarantees that if a client writes a piece of data, any subsequent read by that same client will see that updated value — even if the system is eventually consistent overall.
Without it: You update your profile bio, hit save, the page reloads, and your old bio is still there because your read request was routed to a different, un-synced replica. This is a terrible user experience that erodes trust in the application.
How it's implemented: The system can track a session token or write timestamp for each client. When the client reads, it sends this token, and the system ensures the read is served from a replica that has caught up to at least that write. If no such replica is available locally, the read may be routed to the primary.
2. Monotonic Reads
This guarantees that if a client has seen a particular version of a data object, any subsequent reads by that same client will never return an older version. You cannot "go back in time."
Without it: You refresh a news feed and see a breaking news story. You refresh again, connecting to a different replica that is lagging behind, and the story disappears. This is disorienting and makes the application feel broken.
3. Monotonic Writes
This guarantees that writes from a single client are applied to the system in the order the client issued them. If you write x = 1 and then x = 2, no replica will ever apply x = 2 before x = 1.
Without it: A client appending log entries could have them arrive out of order on different replicas, corrupting the log sequence.
4. Writes-Follow-Reads (Session Causality)
This guarantees that if a client reads a value and then performs a write, that write is guaranteed to happen after the read's version. It's a session-level form of causal consistency — your writes are causally downstream of what you've read.
Without it: A client reads a configuration value, decides to update a dependent setting, but the write lands on a replica that hasn't yet seen the configuration value the client read. The update is applied to stale state.