Synchronous vs Asynchronous Replication: Latency, Durability, and Data-Loss Windows

Learning outcomes

Replication turns one write into a latency-versus-durability path. The important choice is not simply “sync or async”; it is which acknowledgement stage, which replicas, and which failure domains the client success response depends on. AtlasMart will model those stages explicitly so “committed” always has a declared meaning.

1. “Synchronous” describes what the success response waits for

Replication can stream continuously in both asynchronous and synchronous designs. The difference is whether the foreground write path waits for remote evidence before returning success. A leader may locally persist first and then stream. A follower may receive bytes, persist them, or apply them to visible state. Each waiting point produces a different guarantee and latency cost.

For a payment/order transition, AtlasMart may require a durable copy outside the leader's failure domain before acknowledging. For rebuildable clickstream-derived state, leader-local acknowledgement plus asynchronous replication may be acceptable. The policy belongs to the invariant and recovery requirement.

2. Data-loss window = acknowledged history not yet protected against the failure you care about

If the client receives success while the only durable copy is on the leader, the window remains open until another independent durable copy receives the record. If the leader's host dies inside that interval, failover can lose an acknowledged write. If leader and synchronous replica share the same rack or zone, a correlated failure can still remove both copies despite “two acknowledgements.”

This is why durability must be stated against a failure model: process crash, host loss, zone loss, region loss, storage corruption, or operator deletion. Chapter 22 later separates replication from backup and disaster recovery.

3. Remote acknowledgement adds the slowest required path to the write tail

A synchronous policy makes the client wait for required remote evidence. If AtlasMart requires one local-zone follower, the added wait may be small. If it requires a distant region, wide-area round-trip latency and remote storage behavior join the critical path. Tail latency matters: a quorum-like rule can wait for the fastest required subset, while an “all replicas” rule can make one slow replica dictate every write.

4. Concrete PostgreSQL 18 mapping clarifies receipt, durability, and visibility

PostgreSQL 18 documents asynchronous streaming replication as the default. With synchronous replication, a commit can wait for standby feedback. Its synchronous_commit modes distinguish remote write/durable/apply stages; remote_apply waits until a synchronous standby has replayed the commit and made it visible to queries. This is a useful concrete example because it demonstrates that “remote acknowledgement” itself has stages.

Do not copy PostgreSQL option names into another database design and assume identical semantics. The portable lesson is to identify the acknowledgement state precisely.

5. Deliberately wrong approach — “two copies means zone-safe”

AtlasMart configures a primary and synchronous follower, both in zone-a, and declares the service zone-fault tolerant. A power/network event removes the whole zone. Both acknowledged copies disappear together. Numerically there were two replicas; operationally there was one failure domain.

The repair is topology-aware placement plus an acknowledgement rule that waits for the independent domain required by the service objective. Then test the exact domain loss rather than only killing one process.

6. AtlasMart lab — acknowledgement paths and failure windows

from dataclasses import dataclass

@dataclass(frozen=True)
class Ack:
    replica: str
    failure_domain: str
    durable_ms: int
    apply_ms: int

acks = [
    Ack("primary", "zone-a", 2, 3),
    Ack("replica-b", "zone-b", 7, 9),
    Ack("replica-c", "region-west", 74, 78),
]

def policy(name, required):
    selected = sorted(acks, key=lambda a: a.durable_ms)[:required]
    return name, max(a.durable_ms for a in selected), selected

for name, required in [
    ("local-only", 1),
    ("two durable copies", 2),
    ("three durable copies", 3),
]:
    n, latency, selected = policy(name, required)
    print(n, "ack_ms=", latency,
          "copies=", [(x.replica, x.failure_domain) for x in selected])

print("\nFAILURE WINDOWS")
for fail_ms in (3, 8, 75):
    durable = [a for a in acks if a.durable_ms <= fail_ms]
    print("failure at", fail_ms, "ms -> durable copies:",
          [(a.replica, a.failure_domain) for a in durable])

print("\nREMOTE APPLY VS REMOTE DURABLE")
west = acks[-1]
print("remote durable at", west.durable_ms, "ms; visible after apply at", west.apply_ms, "ms")
print("modeled times are teaching inputs, not benchmark measurements")

Verification checklist

• local-only returns at the modeled primary durability time.
• Waiting for two copies waits for the second-fastest required durable copy.
• The remote copy has separate durable and apply timestamps.
• A failure before the second copy is durable leaves only the primary copy.
• You can name the failure domain associated with each replica rather than counting replicas alone.

7. Production judgment and next bridge

Use stronger synchronous acknowledgement for state whose acknowledged loss violates AtlasMart's recovery objectives; use asynchronous replication where lower latency/greater write availability is worth a bounded loss/freshness window. Record per-policy write latency, replication lag, unavailable synchronous replicas, queue depth, and durability location. Rehearse failure at each acknowledgement stage.

Lesson 3 changes the ownership model entirely. Instead of one global write owner, multiple leaders accept region-local writes. That can remove a wide-area leader round trip, but concurrent writes become an application and replication problem rather than something single-leader ownership mostly prevents.

Authoritative references

• PostgreSQL 18 — Synchronous Replication — official acknowledgement stages, synchronous standbys, and latency/high-availability tradeoffs
• PostgreSQL 18 — Replication Configuration — official synchronous standby selection and replication settings
• PostgreSQL 18 — Statistics Views — write/flush/replay lag signals in pg_stat_replication
• MongoDB — Write Concern for Replica Sets — concrete example of per-operation acknowledgement strength and latency/durability tradeoff