Replica lag and read-your-writes consistency

WHAT THIS TESTS This probes whether you understand the consistency cost of asynchronous read replicas and can name a pragmatic mitigation rather than over-engineering it.

A GOOD ANSWER COVERS The phenomenon is replication lag, which causes stale reads: a replica applies the primary's changes a short time after they commit, so a query hitting a lagging replica returns old data. The guarantee users implicitly expect is read-your-writes consistency, meaning after I update my profile I should immediately see my new value. A common application-level strategy is to route a user's reads to the primary for a brief window after they perform a write, often using a sticky session or a timestamp token. Alternatives include reading from the primary only for the affected entity, or waiting until the replica's apply position passes the write's log position.

COMMON WRONG ANSWERS Saying you should make all replication synchronous, which removes the scaling advantage and adds write latency. Claiming the problem does not exist, or proposing client-side caching as the primary fix, which does not address staleness from other clients.

LIKELY FOLLOW-UPS How long should the sticky window be. How do you measure lag. What is monotonic-reads consistency. How would you implement a log-sequence-number token approach.

ONE CONCRETE EXAMPLE A user edits their bio and the write lands on the primary. For the next ten seconds your routing layer sends that user's reads to the primary, so when the profile page reloads they see the new bio. Other users, who do not care about that edit yet, continue reading from replicas without issue.