Synchronous vs. Asynchronous Replication: A Trade-off

WHY IT EXISTS Systems need copies of data for redundancy and performance scaling. The core problem is how to keep these copies updated without crippling the primary system. Replication strategies manage the trade-off between ensuring all copies are identical and keeping the application responsive.

THE MENTAL MODEL Think of it as group communication. Synchronous replication is a conference call: the meeting can't end until everyone on the line hears the decision and confirms it. Asynchronous replication is an email memo: you send it and move on, trusting that everyone will eventually read it.

HOW IT WORKS In synchronous replication, a write to the primary database is not considered complete until all replicas have also received and committed the change. This often uses a two-phase commit protocol. If any replica fails to respond or confirm, the entire transaction is blocked and may be rolled back, even on the primary.

In asynchronous replication, a write is committed on the primary first, and the application gets a success message immediately. The change is then sent to replicas in the background. This creates a delay, known as replication lag, where replicas are temporarily out of sync with the primary.

WHEN TO USE IT Use synchronous replication for tightly-coupled, high-availability clusters where any data loss is unacceptable, like in financial systems. This requires a highly reliable, low-latency network between nodes.

Use asynchronous replication for most other cases: scaling reads with read replicas, disaster recovery sites in different geographic regions, or any scenario where application availability and low write latency are more important than immediate consistency.

WHEN NOT TO USE IT Do not use synchronous replication over a slow or unreliable network, as it will dramatically increase write latency and cause failures if a replica is unreachable. Do not use asynchronous replication if your application logic absolutely requires reading its own writes from a replica immediately after they are made.

ONE CANONICAL EXAMPLE A primary database with two replicas. With synchronous replication, when a user updates their profile, the database server will not confirm the change to the user until it gets a confirmation from both replicas. If one replica is down, the user's update will hang or fail. With asynchronous replication, the database confirms the update to the user instantly and then sends the change to the replicas afterward.