Summary
For cross‑region DB replication, synchronous (sync) prioritizes consistency and zero-loss durability; asynchronous (async) prioritizes low latency and availability. Choose based on RPO/RTO, consistency needs, client latency tolerance, and ops complexity.
RPO / RTO
- Sync: RPO ≈ 0 (no acknowledged writes lost). RTO can be short for read replicas but failover complexity may lengthen recovery.
- Async: RPO > 0 (in-flight transactions can be lost if primary fails); RTO depends on replay backlog and promotion procedures.
Consistency
- Sync: Strong or linearizable consistency between regions for committed writes; eliminates split-brain if properly coordinated.
- Async: Eventual consistency; replicas lag, so reads from secondary may return stale data—requires application awareness or read-routing policies.
Client-perceived Latency
- Sync: Write latency increases by inter-region RTT (can be 50–300ms+), directly impacting user transactions.
- Async: Primary write latency remains low; replicas receive updates later—good for geo-read scaling and low-latency UX.
Operational Complexity
- Sync: Requires robust low-latency links, quorum or distributed consensus (Paxos/Raft) configs, careful failover to avoid blocking; more monitoring and network SLAs.
- Async: Easier to operate and scale across many regions; must handle replication lag, backlog management, idempotency, conflict resolution, and data loss scenarios.
Practical Guidance
- Use sync when zero data loss and strong consistency are business-critical (financial ledgers). Limit to nearby regions or use consensus across nodes to reduce latency.
- Use async for geo-distributed read scaling, disaster recovery, and low-latency writes; combine with techniques like write locality, change data capture, and clear RPO SLAs.
- Hybrid: Synchronous within a region and asynchronous cross‑region is a common compromise.
I would choose based on SLA requirements, typical RTT between sites, and operational readiness (monitoring, runbooks, and failover automation).
