You post a photo on a social media app, then immediately refresh the page and the photo is missing. What session guarantee is being violated here, and what would need to change for the app to satisfy it?

## The promise Read-your-writes (RYW) is one of four 'session guarantees' first formalized by Terry et al. in the Bayou project (1994) to make eventually consistent systems tolerable for a single user, even though the system as a whole remains relaxed. The core idea: from the point of view of one client's own session, time should never appear to run backwards with respect to that client's own actions. If a client just wrote a value, every read it issues afterward must return that value or something even newer, never an older one. ## Why a read can miss its own write Mechanism, step by step: a write is accepted and lands durably on some replica, say A. If the client's next read is load-balanced to a different replica B that hasn't yet received the replicated write, B answers with stale data and the client's own change appears to have vanished. Fixing this requires tying the read to the write in one of a few ways. - **Sticky sessions/session affinity** pin a client's requests to the same replica or partition it wrote to, so subsequent reads naturally see the write. - **Version-stamped reads** have the client carry forward a token (a vector clock entry, a log sequence number, or a simple version integer) returned by the write, and pass it on every subsequent read; the serving replica must either be at or beyond that version, wait until it catches up, or proxy the read to a replica that is. - **Quorum-based systems** get RYW as a byproduct of overlapping read/write quorums (`W + R > N`), since any read set is mathematically guaranteed to intersect the write set. ## What makes this the bug users notice Why it exists: not every client needs strong, system-wide consistency, but every single client cares deeply about seeing the effect of its own actions — it is the single most visible correctness bug an eventually consistent system can produce, because it directly contradicts the user's own recent, remembered action: - a posted comment disappearing, - a saved profile edit reverting, - a removed cart item reappearing. ## What each mechanism costs Trade-offs: - **Sticky sessions** reduce load-balancing flexibility and complicate failover — if the pinned replica or server dies, the client either briefly loses the guarantee or must be handed a durable token it can carry to whatever replica serves it next. - **Version tokens** add protocol complexity (issuing, storing, expiring, and validating them) and can add tail latency whenever the serving replica must catch up before answering. - **Quorum overlap** gives RYW essentially 'for free' but taxes every single read and write with the coordination cost of contacting multiple replicas, even for data nobody but the writer will ever check freshness on. ## How it breaks in production Failure modes in production: RYW quietly breaks 1. when a client's requests get rebalanced across backends after a deploy, connection reset, or autoscaling event that drops sticky affinity; 2. when a CDN or read-through cache sits in front of the version-aware backend and serves stale bytes with no concept of the token at all; 3. or in multi-device scenarios where a naive implementation ties RYW to one TCP connection instead of a durable per-user identity, so a user's phone doesn't see an edit made moments earlier on their laptop (that specific cross-device case is really the job of writes-follow-reads/causal consistency, not RYW as classically defined, but it is frequently what users mean when they report 'my change disappeared'). ## Where you see it in practice Real-world example: - **Amazon DynamoDB** exposes 'eventually consistent reads' (cheap, fast, may violate RYW) and 'strongly consistent reads' (slower, roughly double the read-capacity cost, guarantees RYW and more) as an explicit per-request choice, and engineers are expected to pick strongly consistent reads specifically for the read immediately following a write when the UI must reflect it. - **Azure Cosmos DB's 'Session' consistency level** does the version-token approach directly: every request carries a session token the server must be at or beyond before answering, implementing RYW (and the other three session guarantees) for that one client without paying for full strong consistency platform-wide.