Read-Your-Writes Consistency
also called Read-After-Write
A guarantee that a client always sees its own prior writes, even in a system that is otherwise eventually consistent.
This is the session guarantee that matters most for user-facing systems, because its absence produces the single most alarming class of eventual-consistency bug: a user updates their profile, the page reloads, and the old value is displayed. They update it again. Now there is a support ticket and a belief that the system loses data.
The mechanism is straightforward once named. The write goes to a primary; the subsequent read is load-balanced to a replica that has not yet received it. Nothing is broken and the user experience is indefensible.
The remedies, in increasing generality. Route reads to the primary for a window after a write — simple, and concentrates read load. Sticky routing to the replica that served the write. Token based: the write returns a version or log position, the client presents it on subsequent reads, and the replica waits or redirects until it has caught up. That last is the most robust and is what most mature distributed databases expose.
The broader family is worth knowing because each solves a different complaint: monotonic reads stops time appearing to go backwards across successive reads, and consistent prefix stops causally related events being observed out of order — the reply arriving before the message.