A user posts a comment on a social app, then immediately refreshes the page and sees the comment has vanished. Which consistency guarantee is missing, and how would a system provide it on top of an eventually consistent backend?

## Where these models sit Client-centric consistency models sit in the spectrum between full eventual consistency (no guarantees at all about ordering) and stronger, session-independent models like causal or sequential consistency. Rather than guaranteeing something about how ALL clients see ALL operations — which is what makes causal, sequential, and linearizable consistency expensive — client-centric models only promise something about how a SINGLE client experiences its OWN sequence of reads and writes over a session. The two most important members of this family are read-your-writes and monotonic reads. ## The two guarantees | Guarantee | What it promises | |---|---| | **Read-your-writes** | once a client has completed a write, every subsequent read issued by that same client reflects that write (or a newer one) — never an older value | | **Monotonic reads** | a separate, complementary guarantee: once a client has observed a particular value (or a newer one) for a piece of data, it will never later observe an OLDER value, regardless of who wrote it | The distinction matters: read-your-writes is about a client seeing its OWN writes; monotonic reads is about a client's sequence of observations never moving backward in time, even for values written by someone else. ## How systems implement them Mechanically, systems implement these in a handful of common ways. 1. **Sticky sessions / write-affinity routing** is the simplest: pin a client to the specific replica it wrote to (or one already known to have applied that write) for the duration of a session, so its own reads always land somewhere with the update. 2. **Version-stamped reads** are a more portable approach: the client, or a session token issued by the server, carries the version or log position of its last write; when it issues a new read, the router or replica must prove it is at least that fresh before answering, forwarding the request elsewhere or waiting if not. 3. **Write-through client-side caching** is a third pattern: the application remembers the value it just wrote and serves it directly from a local cache for a short window, sidestepping the backend consistency question for the immediate re-read case. ## Why they exist These guarantees exist because raw eventual consistency, while cheap, produces behavior that looks like an outright bug to an end user even though the system works exactly as designed: - you post something, refresh, and it's gone; - you view a status, refresh, and it reverts. Client-centric models fix precisely this class of complaint — the case a single user cares about most, their own actions — without paying for full cross-client global ordering, which is the expensive part of causal, sequential, and linearizable models. ## What they leave uncovered The trade-off is that these guarantees only cover the client experiencing them; they say nothing about consistency BETWEEN different clients. Two users can simultaneously see completely different states of shared data, and that's perfectly compliant with read-your-writes and monotonic reads. There's also real operational cost: - **Sticky routing** reduces a load balancer's freedom to spread traffic evenly, and it complicates failover — if the replica a session is pinned to goes down, the replacement replica must either already have the client's writes applied, or the system must actively verify or wait for that before answering, adding latency exactly during an already-stressful failover event. - **Version-token approaches** add per-session state that must be threaded through every request across API gateways, mobile clients, and service meshes. ## Failure modes - In production, the most common failure mode is exactly the load-balancer-reroutes-mid-session scenario: a client's read lands on a fresh replica that hasn't caught up, and the read-your-writes guarantee silently breaks — the user sees their edit vanish again, intermittently and hard to reproduce, which makes it a nasty class of bug to debug from support tickets alone. - A second failure mode is **version-token staleness**: if a client-held token isn't correctly updated after every write, later reads can validate against a version that's already behind, defeating the guarantee without any visible error. ## Real implementations - A concrete real-world implementation is **MongoDB's causal consistency sessions**: a client obtains a session, and every operation within it carries a logical `clusterTime` token; the driver ensures reads within that session never observe data older than what the session has already seen, giving both read-your-writes and monotonic reads without requiring the whole cluster to be linearizable. - **Amazon DynamoDB** exposes a per-request `ConsistentRead` flag, letting a caller opt into a strongly consistent read exactly when it needs read-your-writes behavior, leaving the rest of its traffic on cheaper eventually consistent reads.