A user posts a comment from their phone, immediately refreshes the page, and the refreshed view does not show their own comment even though other users' unrelated comments do load. Which causal-consistency guarantee is being violated here, and what does 'session causality' mean in general?

## Which guarantee broke The bug the user reports is a textbook violation of **read-your-writes**, one of four classic 'session' or client-centric consistency guarantees first formalized in Terry et al.'s work on the Bayou system: | # | Guarantee | What it promises | |---|---|---| | 1 | **read-your-writes** | a client's reads always reflect that same client's own prior writes | | 2 | **monotonic reads** | once a client has read a value, it never later reads an older value for the same data | | 3 | **monotonic writes** | a client's writes are applied in the order it issued them | | 4 | **writes-follow-reads** | a client's writes are ordered after any writes it previously read | Together these four are often called **session causality** because they apply causal ordering specifically at the granularity of a single client's session, rather than across the whole system's clients. In the example, the comment write likely landed on one replica, while the page refresh got load-balanced to a different replica that had not yet received that write via replication. Nothing else is broken: other users' unrelated comments load fine, because they came from writes that replica already had. But the user's own action appears to have vanished — the read-your-writes violation. ## Why this class of guarantee exists This class of guarantee exists because full, system-wide causal consistency is not, by itself, enough to protect a single client's mental model in a realistic deployment. A system can correctly preserve happens-before ordering between causally related writes from different clients and still let one client's own successive requests hit different replicas with different replication lag, producing exactly the 'my comment disappeared' anomaly — the second request isn't causally dependent on the first from the store's point of view unless the store is explicitly told they belong to the same session. Session guarantees close that specific, very common gap cheaply, without requiring the full machinery of tracking causal dependencies across every client in the system. ## How they are implemented Mechanically, session guarantees are usually implemented with a lightweight **per-session token** rather than full dependency metadata: after a write, the client (or an edge proxy on its behalf) is handed a token representing the highest write version it has produced or observed. On the next request, that token is sent along, and the serving replica must ensure its local state has caught up to at least that version before answering — either: - by routing to a replica that has; - by waiting briefly for replication to catch up; - or by proxying the read to a more up-to-date replica. This is far cheaper than full causal consistency because it only needs to compare a single scalar or small vector per session, not maintain per-write dependency graphs across the whole system. ## The trade-off The trade-off is that session guarantees are strictly weaker than full causal consistency. - They protect one client's view of its own actions, but say nothing about cross-client causal chains. If user A posts a comment and user B, on a completely different session, replies to it, session guarantees alone do not promise a third user C will see A's comment before B's reply — that requires full causal (not merely session) consistency, with dependency tracking across clients. - Session guarantees also aren't free operationally: enforcing 'read your writes' often means sticky session routing or waiting for a lagging replica to catch up, both trading some load-balancing flexibility or latency for the guarantee. ## Where it shows up The most common production failure mode is precisely the scenario described: users on mobile networks switching between cell towers or WiFi mid-session get routed to a different edge location or read replica than the one their write landed on, and briefly see their own action missing until replication catches up. **Azure Cosmos DB's 'Session' consistency level** is a direct, productized version of this fix: it hands the client an opaque session token after every write and requires it on subsequent reads within that session, guaranteeing read-your-writes and monotonic reads for that client specifically, at a fraction of the cost and latency of the database's 'Strong' consistency level.