In the leader-based replication model, there is a spectrum that defines how replication from the leader to the followers takes place. On one end of the spectrum is the asynchronous replication, which involves the leader registering a change locally and then immediately returning a success message in response to a client’s write request. The leader doesn’t wait for the change to propagate to its followers before informing the client that the client’s write request has been successfully processed. The hope is that the leader will be able to transmit the change to its followers without crashing or some other issue such as a network partition occurring. The pictorial representation demonstrates a fully asynchronous replication scenario:

Writes are accepted at the leader only.

widget

Leader acknowledges the write request to the client without waiting for the request contents to be replicated to the followers.

widget

Followers receive the updates from the leader after the client is already sent a success acknowledgement.

widget

The pro of this approach is that the number of write requests that can be processed by such a system is very high since the leader doesn’t wait for the change to be replicated to its followers. Failure of one or more followers doesn’t hinder the leader and write requests can continue to be processed.

However, the con of this approach is that in case the leader fails before the latest changes can be propagated to the followers, the changes are lost forever. The writes aren’t guaranteed to be durable even when the client has been notified of a successful write as the leader can fail without getting a chance to replicate the write to its followers.