Synchronous vs Asynchronous Replication

## The same pipeline, a different waiting point In both modes the primary does the same work: it executes the transaction, writes the change records to its write-ahead log, and makes that log durable on its own storage. It also streams those records to one or more standbys, which write and replay them. The only difference is whether the primary waits for the standby before telling the client the commit succeeded. ## Asynchronous replication The primary answers the client the moment its own log write is durable. Commit latency is therefore whatever the local storage costs, typically well under a millisecond on modern hardware. The standby applies changes shortly after, and the gap between them is replication lag. Consequences: - Write latency is independent of the network and of the standby, so a standby across a continent, or a temporarily slow one, costs nothing on the write path. - Standby failure is a monitoring event, not an outage: the primary keeps accepting writes. - On a sudden primary loss (host death, power cut, storage failure), everything committed but not yet transferred is gone. That is a non-zero RPO: you can measure it in transactions or in seconds of lag, but you cannot make it zero. This is the default in most deployments because it is cheap and robust, and because for many workloads losing the last second of writes in a rare hard failure is acceptable. ## Synchronous replication The primary sends the records and waits for an acknowledgement from a standby before returning success. Now every commit costs one network round trip plus whatever work the standby must do before acknowledging. Within a data centre or between availability zones in one region, that is typically a fraction of a millisecond to a couple of milliseconds; across regions it is tens of milliseconds and is dominated by the speed of light, which no tuning removes. Consequences: - Any transaction the client was told committed exists on at least two machines, so a failover to that standby preserves it: RPO of zero for acknowledged writes. - Commit throughput for a single session drops in proportion to the added latency, because each session's commits serialise on the round trip. Concurrency and group commit hide much of it in aggregate, but tail latency rises. - If the acknowledging standby disappears, commits block, because the primary can no longer satisfy the promise it makes. That availability cost has to be engineered away deliberately (a quorum of several standbys, an automatic degrade to asynchronous, or an accepted outage). ## The important nuance: what acknowledged means Synchronous is not one thing. The standby can acknowledge when it has received the bytes into memory, when it has written and flushed them to its own durable log, or when it has replayed them so queries on the standby can see them. Each level protects against a different failure and costs differently, and a candidate who says only synchronous means the standby has it has skipped the interesting part. ## An important thing synchronous replication does not give you It does not make the standby's queries current unless the acknowledgement is at the apply level. With acknowledgement at the flush level, the standby has the data durably but may not yet have made it visible, so reads there can still be stale. Synchronous replication is a durability mechanism first; read freshness is a separate decision. ## Choosing Ask what one lost second of committed writes costs. For a payments ledger, a trade capture system, or a system of record whose loss cannot be reconstructed from an upstream source, that is unacceptable and synchronous commit within a region is the answer. For event ingest, telemetry, session state, or anything replayable from an upstream log, asynchronous is right and the money is better spent elsewhere. Many systems mix the two: a synchronous standby nearby for zero-loss failover, plus an asynchronous replica in another region for disaster recovery, since paying cross-region latency on every commit is rarely justified. ## How to present it State the waiting point in one sentence, translate each mode into RPO and commit latency, then immediately raise the two follow-ups an interviewer wants: what the acknowledgement level means, and what happens when the synchronous standby is unavailable.