Asynchronous Replication

Asynchronous replication lets a primary database acknowledge a write before replicas have necessarily received or applied it. This can reduce write latency, but replicas may temporarily lag behind the primary.

In asynchronous replication, the application sends a write to the primary database. The primary commits the change and can acknowledge success without waiting for one or more replicas to confirm that they have persisted the change.

The primary then sends replication data to replicas, which apply the changes independently. The delay between the primary and a replica is called replication lag, and it can vary with network conditions, replica load, or the rate at which changes are generated.

A read directed to a lagging replica may therefore return older data immediately after a successful write to the primary. Applications that require read-after-write consistency commonly route those reads to the primary or use a mechanism that accounts for replica position or lag.

The main trade-off is latency versus durability and consistency across replicas. If the primary fails before a recent change reaches a replica, that acknowledged change may be unavailable after failover, depending on the database's replication and recovery mechanisms.

Key points

• The primary can acknowledge a write without waiting for replicas.
• Replicas can temporarily lag behind the primary.
• Reads from replicas may return stale data.
• Asynchronous replication generally lowers write latency compared with waiting for replica acknowledgments.
• A primary failure can risk losing changes that had not reached a surviving replica.

Interview questions

What is asynchronous replication?

Asynchronous replication means a primary database can acknowledge a write before replicas have confirmed that they received or applied it. The replicas receive changes afterward and may temporarily lag behind the primary. This can improve write latency because the application does not wait for replica acknowledgment. The trade-off is that a replica may contain stale data or miss a recent change if the primary fails before replication completes.

Why would a system choose asynchronous replication?

A common reason is to reduce write latency and avoid making application writes depend on replica response time. It can also allow replicas to be geographically distributed without requiring every write to wait for a remote acknowledgment. The cost is weaker consistency between nodes at a given instant. The design should therefore match the application's consistency requirements.

What is replication lag, and why does it matter?

Replication lag is the delay between a change being committed on the primary and that change becoming available on a replica. It can arise from network delays, replica resource limits, or a replica falling behind its incoming change stream. During lag, reads sent to that replica may return older values than reads from the primary. Monitoring lag is important because excessive lag can affect read correctness and failover safety.

A user creates an account and immediately requests it through a read replica. What problem can occur?

The creation may have been acknowledged by the primary while the replica is still processing the change. A read routed to that replica can therefore fail to find the newly created account. This is a read-after-write consistency issue caused by replication lag. One solution is to route the immediate read to the primary or otherwise ensure the selected replica has caught up.