A distributed key-value store is eventually consistent. Explain what each of these client-side session guarantees promises — monotonic reads, read-your-writes, monotonic writes, and writes-follow-reads — and give one concrete bug that appears when each is absent.

## Where the four come from The four session guarantees were introduced in the Bayou project at PARC in the mid-1990s to give individual clients a locally coherent experience on top of a system that, in aggregate, only promises eventual consistency. They don't strengthen the system's global consistency; they strengthen what one client session — one logical thread of a user's interactions — is allowed to observe. ## The four, one by one - **Monotonic reads** means that once a client has observed a value at version `V`, it will never subsequently observe a value older than `V`, even talking to a different replica. Mechanically this requires the client to carry forward a high-water mark (a version vector, Lamport timestamp, or per-partition sequence number) from each read to the next; the server serving that next read must either route to a replica at or beyond that mark, or block/proxy until it catches up. Without this, a classic bug is a user refreshing a feed and, due to round-robin balancing hitting a lagging replica, seeing a comment count regress from 42 to 40 before jumping back to 42 — visibly incoherent. - **Read-your-writes** ensures a client sees its own writes reflected in its own subsequent reads, implemented via sticky routing, version tokens carried from write acknowledgment to read request, or quorum overlap. Absent, users see their own posts or edits vanish immediately after submitting them. - **Monotonic writes** ensures a single client's writes are applied to storage in the order the client issued them — write `W1` then `W2` must never be applied as `W2` then `W1` on any replica. This matters even within one client because network retries, out-of-order packet delivery, or two concurrent connections from the same client (two browser tabs) can otherwise reorder writes at the storage layer. It is typically implemented by having each client attach a strictly increasing per-client sequence number to its writes, with replicas applying writes only in sequence order, buffering or rejecting arrivals that are out of order. Absent, a user editing a document title twice in quick succession ('Draft' then 'Final') could end up with a replica showing 'Draft' because the second write raced ahead and applied before the first write's retry landed. - **Writes-follow-reads**, also called session causality, is the subtlest: if a client reads value `X` and then performs a write `Y`, that write is causally dependent on `X`, and any replica exposing `Y` must also expose `X` (or something at least as new). Concretely: a user reads a forum post, then writes a reply referencing it; another user must never see the reply without being able to see the post it replies to. It is implemented by attaching the version or vector-clock of everything the client has read to its next write, so the write carries an explicit causal dependency that replicas must respect before exposing it. Absent, you get orphan writes — a reply visible with its parent comment missing, which is confusing and occasionally security-relevant, such as a permission-revoking write becoming visible before the resource it protects. ## What all four cost Trade-offs across all four: each requires carrying and checking session state on every operation, costing client-side bookkeeping, server-side freshness checks, and tail latency whenever the target replica must catch up before answering. None of the four guarantees anything between two DIFFERENT client sessions talking to each other in real time — that is what stronger, system-wide models like causal consistency or linearizability address, at much higher coordination cost. ## How they break in production Failure modes in production: these guarantees silently break 1. when session tokens aren't propagated across service boundaries (a mobile app's token doesn't survive a restart, a microservice fan-out drops a header), 2. when load balancers route around sticky affinity during autoscaling, 3. or when a cache layer such as a CDN or browser cache sits in front of a version-aware backend and serves stale content with no token check at all. ## Where you see it in practice Real-world usage: Azure Cosmos DB's 'Session' consistency level implements exactly these four guarantees for a single client by passing a session token with every request, enforced server-side per-partition; it is Cosmos DB's default and most-used level precisely because it delivers a near-strong-consistency user experience at a fraction of the cost of full strong consistency.