Eventual consistency is fine — until a user updates their profile photo, refreshes, and sees the old one. They don't care that the replica will catch up in 200ms. They think your app is broken. Read-your-writes consistency guarantees that after a client writes a value, subsequent reads from that same client will see the write (or a later version of it). Other clients may still see stale data; that's the trade-off that keeps it cheap.

The problem: in a replicated database, writes go to the primary (or a leader replica), but reads are spread across followers for scale. Replication lag is usually milliseconds, but it's never zero. A user who just posted a comment and gets routed to a lagging follower sees their own comment missing.

Three practical implementations:

• Read from the primary after writing — for a short window (e.g., 5 seconds after a write), route that user's reads to the leader. Simple, but concentrates load on the primary.
• Track the write timestamp/LSN — when a client writes, return the log sequence number. On subsequent reads, the client sends that LSN; the replica waits (or rejects) until it has caught up to at least that point. DynamoDB, Spanner, and Postgres logical replication all support variants of this.
• Session stickiness — pin the user to one replica for the duration of a session. Cheap, but breaks on failover and creates hot replicas.

Real-world example: Facebook's TAO system serves the news feed from eventually-consistent followers, but after you post a comment, your client gets a "read-your-writes" token. For the next few seconds, your reads bypass the cache and hit the primary. Other users still read from followers — they see your comment whenever replication catches up. You always see it instantly.

Rule of thumb: if your replication lag p99 is L milliseconds, give the read-from-primary window a duration of at least 2L. With a typical 50ms p99 lag, a 100–200ms window covers nearly all cases without hammering the leader.

Watch out for: cross-device reads. A user writes on their phone, opens their laptop, and expects to see the change. Session-based stickiness fails here. If this matters, use write-LSN tracking stored server-side against the user ID, not the session.

Read-your-writes is the consistency model users actually feel. Strong consistency is invisible when it works; eventual consistency is invisible most of the time and infuriating the rest. Read-your-writes targets the one case users notice — themselves.