What is Read-Your-Writes Consistency?

Prerequisites(1)

Read-your-writes consistency (also called read-after-write consistency) guarantees that after a user writes data, any subsequent read by that same user will see the write. It does not guarantee that other users will see the write immediately—only the writer themselves.

Why It Matters

Without this guarantee, users experience confusing behavior. You update your profile name, refresh the page, and see the old name. You submit an order, check your order history, and it's not there. These are not bugs in application logic—they are the result of reading from a replica that hasn't caught up with the leader.

Implementation Strategies

Route to leader for recent writes: If the user modified something within the last, say, 10 seconds, route all their reads to the leader during that window. After the window expires, fall back to followers. The challenge is knowing when the user last wrote. You can track this with a per-user timestamp stored in a session cookie or a lightweight in-memory cache.
Track write timestamp, read from caught-up replica: When the leader acknowledges a write, record the leader's current LSN (Log Sequence Number). For subsequent reads, only route to a follower whose replay position is >= that LSN. If no follower has caught up, fall back to the leader.
Sticky sessions: Pin each user to a specific replica using a session cookie or consistent hashing of the user ID. The user always reads from the same replica, which processes writes in order, ensuring monotonic reads. However, this does not guarantee read-your-writes if the pinned node is a follower that hasn't caught up.

Monotonic Reads

A related guarantee: once a user has seen data at time T, subsequent reads should never return data from before T. Without monotonic reads, a user might see their new profile picture on one page load, then see the old one on the next (because they hit a different, laggier follower). Implementation: pin the user to the same replica, or track the highest version they've seen and only read from replicas at or beyond that version.

Cross-Device Consistency

If a user updates their profile on their laptop and immediately checks on their phone, the two devices might be routed to different replicas. Ensuring read-your-writes across devices requires centralizing the "last write" metadata—for example, storing the user's last-write LSN in a shared metadata service rather than a device-local cookie.

**Read-your-writes consistency** (also called read-after-write consistency) guarantees that after a user writes data, any subsequent read by **that same user** will see the write. It does not guarantee that other users will see the write immediately—only the writer themselves.

### Why It Matters

Without this guarantee, users experience confusing behavior. You update your profile name, refresh the page, and see the old name. You submit an order, check your order history, and it's not there. These are not bugs in application logic—they are the result of reading from a replica that hasn't caught up with the leader.

### Implementation Strategies

1. **Route to leader for recent writes**: If the user modified something within the last, say, 10 seconds, route all their reads to the leader during that window. After the window expires, fall back to followers. The challenge is knowing when the user last wrote. You can track this with a per-user timestamp stored in a session cookie or a lightweight in-memory cache.

2. **Track write timestamp, read from caught-up replica**: When the leader acknowledges a write, record the leader's current LSN (Log Sequence Number). For subsequent reads, only route to a follower whose replay position is  = that LSN. If no follower has caught up, fall back to the leader.

3. **Sticky sessions**: Pin each user to a specific replica using a session cookie or consistent hashing of the user ID. The user always reads from the same replica, which processes writes in order, ensuring monotonic reads. However, this does not guarantee read-your-writes if the pinned node is a follower that hasn't caught up.

### Monotonic Reads

A related guarantee: once a user has seen data at time T, subsequent reads should never return data from before T. Without monotonic reads, a user might see their new profile picture on one page load, then see the old one on the next (because they hit a different, laggier follower). Implementation: pin the user to the same replica, or track the highest version they've seen and only read from replicas at or beyond that version.

### Cross-Device Consistency

If a user updates their profile on their laptop and immediately checks on their phone, the two devices might be routed to different replicas. Ensuring read-your-writes across devices requires centralizing the "last write" metadata—for example, storing the user's last-write LSN in a shared metadata service rather than a device-local cookie.

Real-Life: E-Commerce Order Confirmation

Real-World Example

An e-commerce platform uses leader–follower replication with three read replicas:

User places an order: The write goes to the leader. The response includes the leader's LSN: 42850.
User clicks "My Orders": The frontend includes the LSN token (42850) in the request header.
Load balancer checks replicas: Replica A is at LSN 42700 (behind), Replica B is at LSN 42900 (ahead). The load balancer routes to Replica B, which has the order visible.
If no replica is caught up: The system falls back to reading from the leader. This is acceptable because read-your-writes only affects the user who just wrote, which is a tiny fraction of total traffic.

Production implementations:

Amazon Aurora: Provides "session consistency" where the reader endpoint tracks the writer's commit LSN and ensures the reader cluster node is caught up.
Vitess (YouTube): Routes reads to the primary for a configurable window after a write, using GTID (Global Transaction ID) tracking.
CockroachDB: Uses hybrid logical clocks to provide serializable reads that automatically reflect the user's own writes.

Read-Your-Writes Flow

Step 1 of 2