What is Replication?

Database replication is the process of copying and synchronizing data from one database to one or more additional databases. The copies are called replicas.

Distributed systems replicate for three reasons: the data survives the loss of a machine (availability), the system keeps answering when one copy is unreachable (fault tolerance), and reads can be spread across the copies instead of all landing on one server (scalability).

The Usual Shape

Most database systems replicate using a primary-replica relationship between the original and the copies.

The primary server gets all the updates. Those updates then ripple through to the replica servers. Each replica sends back a message saying it received the update successfully, which is what allows the next update to be sent.

That confirmation matters more than it looks. Without it, the primary would have no idea whether a replica is keeping up, falling behind, or gone.

Redundancy and Replication Are Not the Same Thing

These two words get used interchangeably and they should not be. Three differences separate them.

Active or passive. Redundancy is usually passive: the backup component sits there in case of a failure and does no work in normal operation. Replication is active: all the copies are used in some way, whether for spreading read load or for recovery.

What they focus on. Redundancy is about the reliability and availability of the overall system. Replication is about the availability and integrity of the data.

What you actually build. Redundancy might mean identical backup systems or components. Replication means distributing and synchronizing data across systems.

Both aim at high availability, so they are often used together. Redundancy has spare resources ready. Replication keeps multiple active copies of the data.

Three Ways to Replicate

Once the primary has a change, one question decides everything else: does the write count as done before or after the replicas have it?

Synchronous replication

Changes made to the primary are replicated to the replicas before the write is considered complete. The primary waits for the replicas to confirm they have received and processed the change, and only then acknowledges the write.

This gives strong consistency between the primary and the replicas. Every change on the primary is immediately reflected on the copies, so the data is consistent everywhere and the risk of loss or disagreement is small.

The cost is time. Every write now includes a round trip to the replicas, and the replicas may be far away.

Asynchronous replication

Changes are not replicated immediately. They are queued and applied to the replicas later.

That creates a delay between the write on the primary and the update on the replicas, which means the copies can be temporarily inconsistent with the original.

In exchange you get two real benefits. Writes complete quickly, because the primary never waits for confirmation from the replicas. And if one or more replicas are unavailable, the write still completes on the primary, so the system stays available.

Semi-synchronous replication

A combination of the two. Changes are replicated immediately to at least one replica, while the other replicas are updated asynchronously.

The write is not complete until that one replica confirms it has received and processed the change. So you get some of the strong consistency of synchronous replication, with better performance than making every replica confirm.

Choosing Between Them

Read the middle column first. If an acknowledged write must never be lost, you are looking at synchronous, and the slower writes are the price. If the system must keep accepting writes through partial failures and a few seconds of staleness is survivable, asynchronous is the fit.

💡 A good habit in interviews is to name the failure you are protecting against before naming the mechanism. "If the primary dies right after acknowledging, an async setup can lose that write, and for a payment record that is unacceptable, so I would replicate synchronously" is a complete argument. "I would use synchronous replication" on its own is a preference.

Key takeaway: Replication copies and synchronizes data across databases, usually with one primary taking the updates and replicas confirming as they receive them. Redundancy is passive spare capacity focused on the system; replication is active copies focused on the data. Synchronous waits for the replicas, asynchronous does not, and semi-synchronous waits for one.

The next lesson, Replication Methods, covers the topologies these strategies run on, from a single leader to no leader at all.