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.
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."