Replica lag is the delay between changes being made in the primary database and those changes becoming available on its copy—a replica.
Imagine we’re building an online store with two databases:
- The primary database accepts changes: new orders, price updates, and other writes.
- The read replica receives a copy of this data and handles read requests to reduce the load on the primary database.
A user changes their delivery address and immediately refreshes the page. The new address has already been saved in the primary database, but the read request goes to a replica that hasn’t applied the change yet.
As a result, the user sees the old address, even though the update was successful. Once the replica catches up with the primary database, the new address will appear.
Why does this delay happen?
With asynchronous replication, the primary database confirms a write without waiting for the replica to apply the changes. Transferring and processing those changes takes time. A slow network or a heavy load can increase the delay.
How can we handle it?
If a user needs to see newly saved data immediately, we can route that read request to the primary database. For example, after updating an address or placing an order.
One important detail: replica lag doesn’t necessarily mean data has been lost. A replica may simply return outdated information temporarily, and we need to account for that when building an application.