Synchronous vs. Asynchronous Replication: Durability, Availability, and Replication Lag

Hello, and welcome to the replication module of your Designing Data-Intensive Applications reading course. Replication means keeping copies of data on multiple machines. It can improve read capacity, reduce geographic latency, and provide redundancy—but the moment a system acknowledges a write before every copy is updated, it must make an explicit trade-off.

This lesson establishes the central distinction you will use throughout Chapter 5: when is a client allowed to hear “success”? We will connect that decision to durability, availability, latency, and replication lag. The next lesson will follow a write through a single-leader system in more detail, including what can go wrong during failover.

The basic model: leader, followers, and lag

In a common single-leader architecture, one database node—the leader (or primary)—accepts writes. It records each change and distributes those changes to one or more followers (or replicas). Followers can often serve reads, but they may not yet contain the leader’s newest data.

Before considering the trade-off, fix three meanings:

• Durability: after the system acknowledges a write, how likely is that write to survive a relevant failure, such as loss of the leader?
• Availability: can the system continue to acknowledge client writes when some component is slow or unavailable?
• Replication lag: how far a follower is behind the leader. It may be measured in time, log positions, transactions, or bytes of unapplied changes.

A useful way to express time-based lag for a particular write is:

Suppose a leader commits a change at time $t_0$, while follower $F$ applies it at time $t_1$. The lag for that follower and change is $t_1-t_0$. Different followers can have different lag because their networks, hardware, read workload, and backlogs differ.

Lag is not automatically a bug. It is the expected consequence of propagating changes through a distributed system. The practical question is whether the system allows a client-visible success while a lagging replica is still missing that change.

Two different acknowledgement contracts

The following diagram captures the contrast. In both cases, the leader sends the change to followers. The difference is the placement of the client success acknowledgement relative to the followers’ confirmations.

Synchronous replication

With synchronous replication, the leader does not acknowledge a write until it has received confirmation from one or more required followers. In a simple form, the sequence is:

1. The client submits a write to the leader.
2. The leader records the write and sends the replicated change to a follower.
3. The required follower confirms the configured durability condition.
4. Only then does the leader acknowledge success to the client.

The exact condition for a follower’s confirmation matters. Depending on the database and its configuration, a follower may be confirming that it:

• received the change in memory;
• wrote the change to its transaction log;
• flushed that log durably to storage; or
• applied the change so that reads on the follower can see it.

Those are different promises. A follower that has durably logged a transaction is useful for recovery, even if it has not yet applied it to queryable tables.

Synchronous replication therefore strengthens replicated durability. Once the client receives success, at least the leader and the required follower have met the chosen persistence condition. If the leader then fails, a surviving acknowledged follower should have the change available for recovery or promotion.

That guarantee has limits. It depends on the failure model and topology:

• If leader and follower fail together—for example, because they share a power domain or storage system—the replicated copy may not help.
• If only one follower is required, other followers may still lag.
• Synchronous replication by itself does not ensure that every read is current. A client can still read from an asynchronous or not-yet-applied replica.

The price is write latency. The client must wait for at least a network round trip to the required replica plus the replica’s processing and persistence work. A distant replica, a congested network, or slow storage adds directly to the time before success is returned.

It also affects availability. If the required follower is down or cannot keep up, the leader cannot honestly give the promised synchronous acknowledgement. It may block or reject writes, and many systems eventually apply backpressure to clients. The leader may still be running, but the system is unavailable for writes that require that durability guarantee.

Asynchronous replication

With asynchronous replication, the leader acknowledges success after satisfying its local commit condition; it does not wait for followers to confirm.

1. The client sends a write to the leader.
2. The leader commits the write locally and returns success.
3. Followers receive and apply the change later.

This makes the acknowledgement path shorter. The client avoids waiting for a remote machine, so write latency is lower and a slow or failed follower does not immediately stop the leader from accepting writes.

The cost is a window of vulnerability: after the leader has acknowledged a transaction but before a follower has received it durably, the leader may fail. If the system promotes a follower that never received that transaction, the acknowledged write can disappear from the new leader’s history.

This is why asynchronous replication can have a nonzero recovery point objective: after a failover, the system may lose some recently acknowledged data. The exact amount is not necessarily a fixed number of seconds. It depends on the current lag and whether the relevant changes had reached a follower.

Comparing the trade-offs precisely

It is tempting to say “synchronous is safe and asynchronous is fast.” That is directionally useful, but too imprecise for system design. The table below makes the assumptions explicit.

A common real-world configuration is not “wait for every replica” versus “wait for none.” A leader may wait for one designated follower or some configured subset, while replicating asynchronously to the rest. That is still a synchronous acknowledgement policy for the required copies, but it avoids coupling every write to the slowest replica. The important discipline is to state which replicas are required and what they confirm.

The final point from that comparison is operationally important: asynchronous replication does not mean “the leader can safely outrun its replicas forever.” If the leader produces changes faster than followers can receive and apply them, a backlog grows. Systems may monitor lag, add capacity, shed read load from replicas, or throttle incoming writes once lag passes a safety threshold.

What causes lag, and what synchronous replication does not solve

Replication lag often combines several delays:

1. Network delay: transferring data between machines or regions takes time.
2. Leader throughput: a busy leader can generate changes faster than a follower can process them.
3. Follower processing: the follower must receive, log, and usually apply changes while perhaps serving read traffic.
4. Large transactions or slow storage: a large write may take substantial time to replay, causing later writes to queue behind it.

In asynchronous replication, all of these can produce visible stale reads and an enlarged data-loss window during failover. In synchronous replication, they instead tend to show up as slower or unavailable writes, because the leader waits for the required acknowledgement.

That is the core trade-off:

• Asynchronous replication moves delay out of the client’s success path, increasing write availability and reducing latency, but permitting follower lag and possible loss of very recent acknowledged writes after leader failure.
• Synchronous replication keeps a required replica in the client’s success path, increasing the durability of acknowledged writes, but increasing latency and making write availability depend on that replica.

Consider a leader with a local follower and a remote follower. If it uses asynchronous replication, it can quickly acknowledge a customer update while either follower is temporarily slow. If the leader fails before either copy has received that update, a promoted follower may not contain it. If it requires the local follower to acknowledge synchronously, the update is better protected against a leader-only failure—but an outage of that follower now prevents the system from acknowledging writes under the same contract.

When reading Chapter 5, annotate every design with two short statements:

• Acknowledgement rule: “The system returns success after …”
• Failover consequence: “If the leader fails immediately afterward, …”

That habit prevents vague claims about “high availability” or “strong consistency” and forces the real engineering question: what was guaranteed at the instant the client was told the write succeeded?

Key takeaways

Replication provides redundant copies, but its behavior depends on the acknowledgement policy.

• Synchronous replication waits for required replica confirmation before acknowledging the client. It improves durability of acknowledged writes against leader failure, but adds latency and can block writes when required replicas are unavailable or slow.
• Asynchronous replication acknowledges after the leader commits locally. It keeps writes fast and tolerates follower outages better in the short term, but replicas can lag and recent acknowledged writes can be lost during failover.
• Replication lag is the gap between the leader’s state and a follower’s applied state. It arises from network, workload, and processing delays; systems must monitor and manage it.
• A synchronous acknowledgement is not automatically a guarantee that all replicas—or all reads—immediately reflect the write.

Next, we will trace the lifecycle of a write in a single-leader replication system and examine the hazards that arise when a failed leader must be replaced.