Synchronous vs. asynchronous replication

Lesson 4 established that a leader propagates writes to followers. This lesson is about exactly when the leader tells the client "your write succeeded" relative to that propagation — and that timing decision has real consequences for durability.

The leader doesn't acknowledge a write to the client until at least one follower has confirmed receiving it too. This guarantees that once a client is told "success," the data genuinely exists on more than one machine — if the leader dies the instant after acknowledging, the confirmed follower still has the data, and no write is lost.

The cost is latency: every write now waits on a network round trip to at least one follower, on top of the leader's own processing. If that follower is slow or unreachable, the write is blocked (or must be routed around the slow follower, adding real complexity).

The leader acknowledges the write to the client immediately, then propagates it to followers in the background, without waiting.

This is much faster from the client's perspective — no round trip to a follower sits in the critical path. The real risk: if the leader crashes before the background replication completes, a write the client was told succeeded can be permanently lost, because no follower ever received it.

Treating this as one global setting for an entire system wastes the flexibility real workloads need — a social media "like" count and a financial ledger entry have very different tolerance for that lost-write risk. Many production systems configure replication per write, or per table: critical writes (a payment, an inventory decrement) go synchronous, paying the latency cost for the durability guarantee; less critical writes (an analytics event, a view count) go asynchronous, favoring speed since losing one occasionally is an acceptable cost. This mirrors System Design's CAP lesson naming the same "different data, different guarantee" principle for consistency — durability under replication is the same kind of per-data decision, not an all-or-nothing property of the whole system.

Some systems wait for confirmation from at least one follower (not all of them) before acknowledging — durability improves meaningfully over pure async (data exists on two machines, not one, before the client is told "success"), while latency stays bounded by the single fastest follower rather than the slowest one. This is a genuinely common default in production relational databases specifically because it captures most of synchronous replication's safety without most of its latency cost.