Replica lag: why read replicas return stale data
Read replicas apply the primary’s writes asynchronously. Replica lag is how far behind they are — and reads from a lagging replica return old data.
What causes it
If the primary accepts writes faster than a replica can apply them, the backlog grows and lag grows with it. Big batch writes, an undersized replica, or long-running queries on the replica all cause it. The classic bug: a user saves something and the next page, read from a replica, does not show it.
How to recognise it
- Replica lag metric rising during write bursts
- “I saved it but it disappeared” bug reports
- Replica CPU or I/O saturated
The math
Lag (seconds) = unapplied writes ÷ replica apply rate
How to fix it
- Use a larger replica
- Reduce write volume (batch writes)
- Send read-after-write traffic to the primary
Reproduce it in the simulator
Open the simulator, build a small architecture and use Fault injection in the inspector, or push traffic past a component’s capacity.
Learn more
Part of the guide Caching in system design.