Session Guarantees: What Users Actually Notice

Why this matters: the bugs users file are almost never "the system was not linearizable." They are "I posted a comment and it vanished." Session guarantees are the cheap, targeted fixes for those complaints — and knowing them is how you avoid reaching for strong consistency you do not need.

Key takeaway

Session guarantees apply per client, not globally. They are far cheaper than linearizability because they require no agreement between clients — only that one client sees a sensible view of its own history. Most "we need strong consistency" instincts are really a need for read-your-writes.

The bug that starts every conversation

In Lesson 6's eventual-consistency walkthrough, Alice wrote x = 10, got an acknowledgment, then read back 2. Reproduce that in a product and it looks like this:

Nothing is broken. Replication simply had not arrived, and the load balancer sent the follow-up read somewhere else. The user does not care about the distinction.

The four guarantees

Guarantee	Promise to one client	Bug it prevents
Read-your-writes	You always see your own writes	"My edit didn't save" / "My comment vanished"
Monotonic reads	You never see data move backwards in time	Refreshing the page and losing content that was there
Monotonic writes	Your writes apply in the order you issued them	A rename landing before the create it depends on
Writes-follow-reads	Your write is ordered after the read that caused it	A reply visible to others before the comment it answers

Read-your-writes

Also called read-after-write consistency. After you successfully write, your subsequent reads reflect it. It says nothing about other users — Bob may still see the old value, and that is fine.

Three standard implementations, in increasing sophistication:

Read from the leader for data you own. Simple, and the most common. A user's own profile always reads from the primary; everything else can read from a follower.
Sticky routing. Pin a session to one replica for a window, so reads land where the writes went. Cheap, but fragile — the replica dies and the guarantee dies with it.
Version tokens. The write returns a version (a log sequence number or timestamp); the client sends it back with subsequent reads, and any replica either waits until it has caught up to that version or forwards the read. This is the robust version and the one to name in an interview.

Monotonic reads

Time must not run backwards for a single client. Without this guarantee:

The user sees content, refreshes, and watches it disappear. Monotonic reads forbids that. The usual implementation is to route a given client's reads consistently — hash the user ID to a replica — so they only ever move forward through that replica's history.

Monotonic writes

Your writes are applied in the order you issued them. Without it, a client that writes A then B can have B applied first on some replica. Create-then-rename becomes rename-then-create, and the rename fails against a row that does not exist yet.

Writes-follow-reads

If you read a value and then write something based on it, everyone sees your write after the value it responded to. This is the session-scoped version of causal consistency — it is exactly what stops a reply from being visible before its parent comment.

Why this is the pragmatic sweet spot

Session guarantees are cheap because they need no cross-client agreement. Read-your-writes requires one client to track one watermark. Linearizability requires every node to agree on a single global order, on every operation, forever. The first is a header; the second is a consensus protocol on the write path.

Choosing quickly

Symptom in the bug report	Guarantee you need	Cheapest fix
"My change didn't save"	Read-your-writes	Read own data from the leader
"Content disappeared on refresh"	Monotonic reads	Pin the client to one replica
"Operations applied out of order"	Monotonic writes	Per-session write ordering / single write path
"A reply showed before its comment"	Writes-follow-reads	Causal metadata on the write
"Two users saw different balances"	None of the above	This one genuinely needs strong consistency

That last row is the point of the table. Four out of five complaints that sound like they demand linearizability are fixed by a session guarantee at a fraction of the cost. The fifth is real — and now you can defend spending on it.