concept

Synchronous vs Asynchronous Replication

Whether a write is acknowledged only after a replica has it, trading write latency against the amount of data a failure can lose.

replicationdurabilitylatency

Synchronous: the primary waits for at least one replica to confirm before acknowledging. RPO is zero for the covered failure — the acknowledged write exists in two places. The cost is that the replica's round trip is on every write, which is a millisecond within a zone, several across zones, and tens of milliseconds across regions. Worse, an unavailable replica now blocks writes unless the primary is allowed to fall back.

Asynchronous: the primary acknowledges immediately and ships changes in the background. Write latency is local. The cost is a non-zero RPO — a primary failure loses whatever had not yet replicated, which is usually milliseconds and occasionally much more if the replica was lagging.

The middle option most systems actually use is quorum or semi-synchronous: wait for some replicas, not all. PostgreSQL's ANY 1 (...), MySQL semi-sync, and majority write concerns in distributed stores all do this — bounded latency, meaningful durability, and tolerance of one replica being down.

The decision belongs to the business as an RPO question, and it should be asked with the latency cost attached: "zero data loss, at 15% higher write latency on every transaction, forever."