Client-Centric Session Guarantees

Placing session guarantees on the consistency spectrum

Level 3's "Replication Lag & Session Guarantees" lesson introduced the four client-centric session guarantees (from the Bayou system) and how to implement them. This lesson credits that treatment and adds the theory frame the interview rewards: where these per-client promises sit on the consistency spectrum from the previous lesson, and why they are the pragmatic default for user-facing reads.

A self-contained recap of the four, since nothing here is corrupted (a read just hit a replica that lags the primary, and each guarantee cures one symptom of that lag):

• Read-your-writes: after you write a value, your own later reads never return an older one.
• Monotonic reads: once you have seen a value, later reads never show an earlier state.
• Monotonic writes: your writes are applied in the order you issued them.
• Writes-follow-reads: if you read X and then write Y in response, everyone sees X before Y.

Implementation was covered in depth in Level 3, so one line here: pin a user's reads to the primary or a caught-up replica for a short window after a write (sticky routing, single-device), or return a logical version token (an LSN or commit timestamp) that later reads carry so the read path waits for a replica caught up past it (version tokens, the only option that survives the phone-write then laptop-read cross-device case, because a cookie-scoped sticky session does not travel).

Where they land, and why that is the point

The previous lesson lined up the global models: linearizable, sequential, causal, eventual, ordered by how much they constrain what all clients observe. Session guarantees are a different cut of the same problem. They are client-centric: each one constrains only what a single client sees of its own actions, and says nothing about how two different users are ordered relative to each other. That is exactly why they are cheap, and why they do not sit as one point on that global line.

Two framings worth carrying into an interview:

• Relative strength. For one client's own view the guarantees are real, but globally they are weaker than causal consistency: causal ordering holds across all observers, session guarantees hold only within your own session. Taken together, the four compose to per-client causal consistency, not the global causal consistency of the spectrum lesson.
• Why they win in practice. Almost every "the app feels broken" report (you edit your bio and the old one returns, a thread flickers between 8 and 10 comments) is a per-user staleness bug, not a cross-user ordering bug. Session guarantees kill exactly that class for the cost of a token compare while leaving the read fleet unpinned. The senior move is refusing to reach for linearizability when the product only needs "the user sees their own action," and reserving the strong end for genuinely global invariants (a uniqueness check, a lock, "claim this seat").

Recap: session guarantees are the client-centric cut of the consistency spectrum, weaker than global causal because they bind only one client's own view (though the four together give per-client causal); implement them with sticky routing or version tokens (Level 3 has the depth), and prefer them over linearizability for user-facing reads, escalating only for truly global invariants.