# Synchronous vs Asynchronous replication

> Synchronous replication waits for the required replica acknowledgments before reporting write success; asynchronous replication reports success without waiting for remote replication. Choose synchronous replication when acknowledged writes must survive the specified failures, and asynchronous replication when lower write latency or continued writes during replica outages matter more than avoiding a potential loss window.

Source: https://sysround.com/compare/synchronous-vs-asynchronous-replication
Updated: 2026-11-05


## Side by side

| | Synchronous | Asynchronous replication |
|---|---|---|
| Write acknowledgment | Waits for required replicas | Does not wait for remote replication |
| Write latency | Includes required replica communication and acknowledgment | Independent of remote acknowledgment latency |
| Acknowledged data loss | Preventable within the configured failure model | Possible if unreplicated writes are lost |
| Replica outage or partition | Writes block or fail if required acknowledgments are unavailable | Leader can continue while local capacity and safety rules allow |
| Replica reads | Can still be stale if acknowledgment precedes apply | Can be stale due to replication and apply lag |
| Failover | Must preserve committed writes and fence the old leader | May lose the missing tail; still requires fencing |
| Cross-region use | Remote acknowledgment adds WAN latency | Avoids WAN acknowledgment on the write path |
| Typical fit | Durable authoritative state | Read replicas and disaster recovery with nonzero RPO |

## The differences that matter

The key difference is the acknowledgment boundary. A synchronous policy might require one standby or a quorum, not every replica. Specify whether acknowledgment means received in memory, persisted to durable storage, or applied to queryable state. These are different guarantees.

Synchronous replication puts the required replicas on the write path. A slow replica matters only if the acknowledgment policy needs it. With asynchronous replication, lag normally stays off the write path, but a growing backlog can exhaust retained-log storage or trigger throttling.

Durability depends on both replication and failover rules. Synchronous durable acknowledgments can protect successful writes against specified failures, but promoting an arbitrary stale replica can still lose data. Asynchronous failover can discard acknowledged writes that never reached the promoted replica.

Replication timing does not determine read consistency by itself. A synchronously persisted log entry may not yet be applied on a read replica, and linearizable reads require an appropriate read protocol. For asynchronous replicas, read-your-writes may require leader reads or waiting until a replica reaches a session's write position.

A common regional design uses synchronous replication across availability zones and asynchronous replication to another region. This limits local failure exposure without adding cross-region acknowledgment latency to every write, but a full regional loss can still lose the unreplicated tail.

## Choose Synchronous when

- A successful payment or ledger write must survive the loss of a database node or availability zone, using durable acknowledgments and safe failover.
- Acknowledged seat reservations or inventory claims must not disappear after the failures your design promises to tolerate.
- A replicated message log must preserve committed entries when leadership changes.
- Your latency budget can accommodate required replica acknowledgments, and you prefer rejecting writes to accepting them without the required durability.

## Choose Asynchronous replication when

- You need geographically distant read replicas without putting cross-region round trips on the primary write path.
- Your disaster-recovery policy explicitly permits a nonzero recovery point objective, meaning some recent acknowledged writes may be lost.
- You must continue accepting writes during remote replica outages and can manage replication backlog and possible failover loss.
- Replica data serves dashboards or other stale-tolerant reads, while authoritative operations use the leader.

## Worked example: Regional durability for a booking service

Suppose a booking service accepts 2,000 reservations per second. Its requirement is that an acknowledged reservation survive one availability-zone failure, while regional disaster recovery may lose up to five seconds of writes. Use durable synchronous replication across zones with a safe promotion policy, then asynchronous replication to a second region. If the remote replica is three seconds behind when the primary region is lost, about 6,000 acknowledged reservations may be missing at that instant. That estimate assumes a steady write rate and measured lag, not a guarantee. If regional data loss is unacceptable, require cross-region durability before acknowledgment and budget for the added latency and partition behavior.

## In the interview

- Start with the failure model: one process, one availability zone, or an entire region. State which failures acknowledged writes must survive.
- Define success precisely: for example, the leader and one standby have durably persisted the log. Expect questions about quorum membership and which replica may become leader.
- Separate durability from read consistency. Explain where reads go, whether stale reads are allowed, and how a client gets read-your-writes behavior.
- Describe a partition explicitly: which side may accept writes, what happens when required acknowledgments disappear, and how the old leader is fenced.
- State both RPO and RTO. Replication policy affects potential data loss, but detection, promotion, routing, and recovery procedures also determine downtime.

## Common mistakes

- Saying synchronous replication always waits for every replica or automatically makes every replica read linearizable.
- Claiming zero data loss without specifying durable acknowledgments, the tolerated failures, and safe promotion rules.
- Treating asynchronous replication as a hard bound on data loss. Lag can grow during outages, so a normal lag measurement is not a guaranteed RPO.
- Confusing replication with backup or transaction concurrency control. Replication can copy accidental deletes, and neither mode alone prevents overselling.

## Interview questions where it comes up

- [Design a payment system](https://sysround.com/questions/design-payment-system): Acknowledged ledger writes need an explicit durability guarantee that survives safe database failover.
- [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Confirmed inventory claims must survive failover, while concurrency control separately prevents overselling.
- [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): The acknowledgment policy and leader election rules determine whether committed log entries survive replica failures.
- [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Replication mode directly shapes write latency, partition availability, stale reads, and recovery behavior.
- [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Asynchronous replica failover can lose recent cache updates, so the answer should distinguish rebuildable data from authoritative state.
- [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Safe promotion requires checking replica progress, preserving committed writes, and fencing the previous leader.

## FAQ

### Is synchronous replication always strongly consistent?

No. Synchronous replication describes which replica acknowledgments a write waits for, not how every read is served. Strong read guarantees also depend on leader authority, commit and apply state, and the read protocol.

### Can asynchronous replication lose committed data?

Yes, if success is reported before replication and the only durable copy becomes unavailable or is destroyed. Promoting a replica that lacks those writes makes them absent from the new authoritative history. If the old storage later returns, reconciliation may be possible, but automatic recovery is not guaranteed.

### Can you use synchronous and asynchronous replication together?

Yes. A database can wait for durable acknowledgments from nearby replicas while shipping changes asynchronously to distant replicas. State which failures the synchronous group covers and what data-loss window remains for regional failover.

## Related concepts

- [Database replication](https://sysround.com/concepts/replication)
- [Quorums](https://sysround.com/concepts/quorums)
- [Eventual consistency](https://sysround.com/concepts/eventual-consistency)
- [Multi-region architecture](https://sysround.com/concepts/multi-region-architecture)
- [Failover](https://sysround.com/concepts/failover)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.