Synchronous vs asynchronous replication trade-offs

WHAT THIS TESTS It checks whether you understand that replication is a tunable tradeoff between commit latency, availability, and how much recently committed data you can afford to lose.

A GOOD ANSWER COVERS Synchronous replication: the primary does not acknowledge the commit to the client until a replica has durably received the change. This guarantees that an acknowledged write survives a primary crash, so failover loses no committed data. The cost is that every commit waits on network round trips and the slowest synchronous replica, raising latency, and if the required replica is unreachable, writes can stall, hurting availability.

Asynchronous replication: the primary commits and acknowledges locally, then streams changes to replicas in the background. Writes are fast and the primary stays available even if replicas lag or fail. The risk is the lag window; if the primary dies before a recent write reaches the replica, that write is lost on failover.

LIKELY FOLLOW-UPS What is semi-synchronous replication, how does quorum or majority acknowledgment fit in, how do you bound replication lag, and how does this relate to RPO and RTO targets.

ONE CONCRETE EXAMPLE A payments ledger uses synchronous replication to a standby so a confirmed payment can never vanish, accepting a few extra milliseconds per commit. An analytics event pipeline uses asynchronous replicas for cheap read scaling, tolerating a small lag because losing a few seconds of clickstream during a rare failover is acceptable.