In a single-leader replication setup, what's the practical difference between synchronous and asynchronous follower replication, and what does each cost you?

## What the choice actually decides Synchronous and asynchronous replication describe **when the leader is allowed to tell a client 'your write succeeded,'** and that timing decision is really a trade-off between durability, latency, and availability. Mechanically: - **Synchronous replication** - the leader appends the write to its own log, sends it to one or more designated synchronous followers, and only returns success to the client after receiving acknowledgment that those followers have durably persisted the write too. - **Asynchronous replication** - the leader appends the write locally, immediately returns success to the client, and then streams the write to followers on its own schedule, with no client-visible wait for their acknowledgment. The leader and followers still apply writes in the same order in both modes - the difference is purely about when the client is told 'done,' not about ordering. ## Why the distinction exists This distinction exists because a system has to decide how much it is willing to trust a single machine (the leader) with data before it's copied anywhere else. If a leader acknowledges a write and then immediately crashes before ever replicating it, that write is gone from the cluster's perspective - the client believes it succeeded, but no surviving node has it. Synchronous replication closes that window by refusing to acknowledge until the data exists on at least one other machine, so a leader crash right after acknowledgment cannot lose data (assuming the synchronous follower is promoted). Asynchronous replication accepts that risk in exchange for speed and availability. ## The trade-off, on both axes The trade-off is genuinely two-sided and shows up on both axes. | Axis | Which mode wins, and why | |---|---| | Latency and availability | Favor **asynchronous**: the client doesn't pay network round-trip cost to a follower on every write, and the leader keeps accepting writes even if every follower is down, slow, or network-partitioned - the leader just gets further ahead and followers catch up later. | | Durability | Favors **synchronous**: an acknowledged write is guaranteed to exist on more than one node, so failover after a leader crash never silently drops a 'successful' write. | But synchronous replication pays for that guarantee with tail latency (every write waits for the slowest required follower's round trip) and a nastier availability failure mode - if the synchronous follower becomes unreachable, the leader can't safely acknowledge any write at all, so the whole system can grind to a halt on a single follower outage unless it's designed to fail open (demote to async) or fail closed (block writes) under that condition. ## The middle ground In practice almost nobody runs pure synchronous replication to every follower, because losing any one of N followers would stall all writes. The common middle ground is **semi-synchronous replication**: one follower (or a rotating subset) is designated synchronous and must acknowledge before the client gets a response, while the remaining followers replicate asynchronously in the background. This bounds the durability guarantee ('the write survives loss of the leader alone') without paying the cost of waiting on every follower, and if the synchronous follower goes down, the system typically promotes a different follower to synchronous status so writes can keep flowing with only a brief gap in the stronger guarantee. ## Failure modes Failure modes differ sharply between the two. - **With pure async**, the dangerous scenario is: leader acknowledges a write, leader crashes before shipping it to any follower, a follower is promoted, and the write is permanently gone - the client was lied to. This is the classic cause of 'I saved my order and it disappeared after a failover' incidents. - **With sync (or semi-sync)**, the dangerous scenario is availability collapse: a synchronous follower experiences a slow disk, GC pause, or network blip, and every write in the system now waits on it, turning a single slow machine into a cluster-wide write stall; operators have to watch for this and either time out and demote the laggy follower or accept the stall as the cost of the durability guarantee. ## Where it shows up A concrete real-world example: MySQL semi-synchronous replication requires at least one replica to acknowledge receipt of a transaction before the primary commits, which is a deliberate middle ground between MySQL's default fully-async replication and a fully synchronous setup; PostgreSQL similarly supports naming synchronous standbys to require acknowledgment from one or more named standbys, with the well-known operational hazard that if the named synchronous standby is unreachable, write transactions on the primary hang until it recovers or an operator reconfigures the setting. This is precisely why teams pick asynchronous replication for latency-sensitive, high-write-volume systems where losing a few recent writes on a rare crash is an acceptable risk, and reserve synchronous or semi-synchronous replication for data where losing an acknowledged write (e.g., a financial transaction) is unacceptable even at the cost of higher write latency and a narrower availability envelope.