Read-Your-Writes Consistency

Overview

Read-your-writes, or read-after-write, consistency ensures a client sees the effects of its own earlier updates. It is a session guarantee that sits between eventual consistency and linearizability, and fixes the common confusion where a saved edit seems to disappear after reload.

How it works

The write returns a position marker; subsequent reads only use replicas that have reached it.

POST /profile  -> primary commits at LSN 4821
               <- cookie: minLsn=4821
GET /profile   -> router picks replica R
   if R.replayLsn >= 4821: read from R
   else: read from primary (or wait briefly)

Simpler variants route a user's reads to the primary for N seconds after any write, with N longer than typical replica lag. Dynamo-style stores achieve the effect by using quorum reads or sticky sessions. For multi-device users, store the last write position server-side keyed by user id.

Pitfalls

• A fixed time window fails when lag spikes during load or maintenance; position-based checks adapt.
• Reading everything from the primary after writes can overload it during write bursts.
• Different devices share no cookie, so the token must live server-side.
• Reads of resources written by other users can still be stale; this is not monotonic reads or causal consistency.
• Caches in front of replicas can serve old values; invalidate or version them on write.

Key takeaways

• Pass a write position with the session and check replicas against it.
• Fall back to the primary when no replica is fresh enough.
• Monitor replication lag, since the guarantee degrades into primary load when lag grows.