Replica Lag, Read-Your-Write, and Version Cursors

Working case

Reviewer 29 saves case 62 at revision 47 in the write region. The API returns revision 47. A detail refresh from another region reaches a replica still at 46. Rather than render revision 46 as a clean success, the read path sees the minimum revision and routes to the writer or returns a bounded retry state. An unrelated public case list may tolerate a short lag and label its freshness separately. Reviewer 29’s next edit still uses a conditional write against the current authoritative revision to prevent a lost update.

Implementation boundary

function mayServeReplica(appliedRevision, minimumRevision) {
  return appliedRevision >= minimumRevision;
}
console.log(mayServeReplica(46, 47));
// Output: false

Choose which operations require read-after-write and which can tolerate delay. Return a durable version or commit token from a successful write. On subsequent reads, carry a minimum version and compare it with the replica’s applied position; do not compare wall clocks as if they were commit order. If the replica is behind, use a documented fallback and deadline. Keep pagination cursors tied to stable ordering and version assumptions, because a page served from another replica may appear to jump. Measure lag at the application-visible read boundary, not only at replication internals.

Cost and boundaries

Waiting for a replica adds tail latency, while routing to the writer raises load and cross-region network cost. Stronger synchronous replication can reduce stale reads but increases write latency and coordination cost. A version token adds small request metadata and observability complexity. Read-your-write guarantees may need a sticky or primary read window after writes, but an indefinite sticky policy can defeat regional locality. Track stale-read rate, fallback-to-writer share, version wait time, and conditional-write conflicts by operation.

Failure trace

The browser saves revision 47, immediately loads revision 46, and overwrites its form with stale data. The user then writes a second edit against old state. Test rapid refresh, cross-region route change, account switch, stale list plus current detail, a replica paused for 62 seconds, and a primary read timeout. Confirm that a deadline yields a clear pending or failure state, not silent acceptance of revision 46. Verify a stale read never resets the client’s known minimum version.

Verification

• A post-save read does not silently show an older revision.
• Replica waits and writer fallback have deadlines.
• Conditional writes still guard concurrent edits.

Practice drill

Simulate a writer at revision 47 and a replica at 46. Run reads with and without a minimum revision requirement. Show the approved fallback and its deadline. Advance the replica to 47 and repeat. Save again through a conditional write while another reviewer has changed the case, and verify the conflict contract. Compare user-facing latency and writer load for local stale reads, bounded waits, and primary routing.

Decision note

Name freshness needs per operation and carry a version token across the write-to-read boundary.

Common Mistakes

• Using wall-clock timestamps as commit versions.
• Assuming a read replica is current after a fixed sleep.
• Letting stale data reset the client’s known revision.

Connected lessons

Build Project: two-region case service recovery and review Web Development: motion and regional state decisions quiz; follow Multi-Region Web State and Recovery; Regional Routing, Static and Private Cache Boundaries; Regional Failover, Fencing, and Replay; Regional Data Location and Operational Evidence; Conditional Writes and Lost-Update Prevention; Client Cache Keys and Invalidation.