Read-your-writes breaks quietly

A user saves a change and the next page does not show it. The write landed on one replica and the read went to another that had not caught up (A replica is only as current as its lag). No error appears; the read is just stale, and the user may save again.

Read-your-writes consistency promises users their own updates, not everyone else's. With a single leader the fix is to send that user's next reads to the leader. Neo4j shows another: a write returns a bookmark, and a later read carrying it is served only by a replica that has applied that transaction.

Regions strain both. DynamoDB global tables accept writes in any region, but a strongly consistent read sees only the latest value in its own region, and a newer write elsewhere can take seconds to arrive. A leader read also fails if the leader is unavailable, as during a failover. After a lossy promotion, something a user already saw can be gone: Redis may promote a replica that is behind. A quorum read avoids asking where the leader is, by contacting a majority.

Failing over can break it even on a database that promises strongly consistent reads, because that promise may stop at the region boundary.

The repeated save is a separate problem, solved by a client-generated request ID.