Read-Your-Writes Consistency
Read-your-writes guarantees a user sees their own completed updates on subsequent reads — demanding session affinity or propagation tracking in replicated and cached systems.
Definition
Read-your-writes (session consistency) requires that once a write completes for a client, later reads by that client reflect it. Behind replication and caching, a write lands on one replica while reads route anywhere, so the guarantee needs session pinning to the written replica, propagation delay tracking per key, or read-token mechanisms. Other clients may still see stale data — the guarantee is per session.
Context and scope
Matters for profile edits, shopping carts, settings changes, and content management previews behind eventually consistent stores, CDNs, and cache-aside layers.
Common misconceptions
- Eventually consistent stores cannot offer it — they can, per session, by pinning or tracking; the guarantee is weaker than linearizability but sufficient for UX
- It requires reading from the primary — replica reads serve it too when the session routes to a replica caught up past the client write timestamp
- CDN caching makes it impossible — scoped cache keys per user or short TTLs on user-scoped resources restore it at cache cost
Anti-patterns
- Round-robining reads across replicas and showing users their old profile right after saving the new one
- Cache-aside with long TTLs on user-editable resources and shipping the classic stale-after-save bug
- Assuming the same solution fits all users — session consistency for the writer is cheap; global monotonic reads for everyone is a different, costlier guarantee
Related concepts
Authoritative source
What it is
The user saves, the page reloads, the old value stares back. That is a read-your-writes violation: replication or caching served a view older than the user own write. The guarantee says a session reads never regress below its writes.
How it works
Mechanisms: session stickiness to the replica that accepted the write until it confirms propagation; timestamp or vector tracking so reads wait for or route to replicas past the write; write-through caches that bypass on the next session read; and client-side read tokens carrying the last write version. Each trades latency or complexity for the guarantee.
When to require it
Any user-visible save-then-read flow: profiles, settings, carts, published content preview. Multi-device sync raises the bar to monotonic reads across devices, which needs cross-session coordination.
Pitfalls
Session affinity concentrates load on one replica and interacts badly with failover — combined with lag tracking it survives reroutes. CDN layers must participate: user-scoped resources need per-user keys or authenticated edge caching, or the violation moves from database to edge. Load balancer connection reuse silently breaks affinity assumptions during scale events.