Replication lag & read-your-writes
Replication lag & read-your-writes
Silver
Read replicas apply the primary's changes a little later — usually milliseconds to a second, but longer when writes surge, a replica is busy or a transaction is big, and with no fixed upper limit. A read that lands on a replica in that gap returns stale data, such as an expense you just added missing from the list. Read-your-writes is the promise that you always see your own changes; apps get it by sending a user's reads to the primary for a short while after they write, or by remembering the position of their last write and reading only from a replica that has caught up to it. Synchronous replication closes the gap but makes every commit wait for the replica.
- Use when
- Reads after a user's own change — their new expense, their edited expense — must show that change · Some screens tolerate a little staleness and some don't, and you want replicas for the first kind · Deciding which writes are worth waiting for a second copy before confirming
- Avoid when
- Every reader must see every write at once — that is a stronger guarantee than read-your-writes (Consistency line) · Routing every read to the primary just to be safe — it gives up the read capacity replicas were added for
- Trade-offs
- Primary-after-write is simple, but the window guesses at lag that has no upper bound · Tracking the write position is exact, but every read must carry it and may wait for a replica to catch up · Synchronous commits survive a primary failure without losing writes, but every commit pays a round trip to the replica
- Requires
- Read replicas
3 objectives · 5 misconceptions
- predict Predict when a read sent to a replica returns stale data, and how the share of stale reads changes as write load and lag grow.
- choose Choose a routing rule — always primary, primary for a window after a write, or replica once caught up — that gives read-your-writes for the reads that need it while keeping most reads on replicas.
- explain Explain what synchronous replication buys and costs compared with asynchronous — commit latency against losing the newest writes when the primary fails.
- Not true: Replication lag is a fixed, small delay you can set once and forget.
- Not true: Read-your-writes means every user sees the newest data.
- Not true: The only way to avoid stale reads is to send every read to the primary.
- Not true: Synchronous replication removes stale reads at no cost.
- Not true: Waiting a fixed second after a write is always enough for every replica to catch up.