Premium Video

This video is available to premium subscribers only

Unlock Full Access

Suppose an application stores all of its data on a single database server. At first, this may work perfectly well.

But that database becomes a critical dependency. If the server fails, the application may lose access to its data. And as traffic grows, that one database may also struggle to handle every read and write request.

One way to improve this is to maintain additional copies of the database on other machines. If one server becomes unavailable, another copy may be able to take over. And if the application receives a large amount of read traffic, some of those reads can be distributed across the copies.

That is the basic idea behind database replication.

This chapter covers what replication is, why systems use it, and the trade-offs that come with keeping copies of the same data on multiple database servers.

Database replication means keeping copies of the same data on multiple database servers. Each copy is called a replica.

For example, suppose a user changes their email address. The update is written to one database server. The replication system then sends that change to the other replicas so they can update their copies as well.

A common replication model uses one primary database and several replicas.

The primary, sometimes called the leader, handles writes. So inserts, updates, and deletes are sent to the primary. The primary then records those changes and sends them to the replicas. The replicas apply the same changes to their own copies of the data.

Reads can still go to the primary. But in many systems, read requests are distributed across the replicas. This allows the primary to focus more of its resources on processing writes.

Replication usually works by transmitting changes rather than copying the entire database again for every update.

Suppose the primary receives an update to an order. The database records that change in an internal log. That log might describe operations such as inserting a row, modifying a value, or deleting a record. The replicas continuously receive those changes and apply them locally.

Different database systems implement this in different ways. Some replicate low-level storage changes. Others replicate logical operations.

But the basic idea is the same: capture the changes happening on one database and replay them on other databases.

Replication provides several important benefits.

So replication is not only about backups. It can improve availability, scalability, and performance while the system is running.

One important decision is when a write should be considered successful.

With synchronous replication, the primary waits for one or more replicas to confirm the write before returning success to the client.

Suppose a user updates their profile. The primary writes the change locally. It then sends the update to a replica. Only after the replica confirms that the change has been stored does the primary respond to the client.

The advantage is stronger durability. Even if the primary fails immediately afterward, another server already has the latest change.

But there is a cost. Every write now depends on communication between multiple machines. If the replica is far away or temporarily slow, write latency increases. And if the required replica is unavailable, the write may fail even though the primary itself is healthy.

The other common approach is asynchronous replication.

Here, the primary does not wait for the replicas before responding. It stores the write locally and immediately tells the client that the operation succeeded. The replicas receive the update shortly afterward.

This makes writes faster because the client does not need to wait for another server.

But it introduces a risk. Suppose the primary accepts a write and returns success. Before that write reaches any replica, the primary fails. The latest change may be lost.

So asynchronous replication generally gives better write performance, but weaker guarantees during failures.

Asynchronous replication also introduces something called replication lag. A replica may be slightly behind the primary.

Suppose a user changes their profile picture. The write goes to the primary. A few milliseconds later, the update reaches the replica. During that short window, the replica still contains the old profile picture. If the application sends the user's next read to that replica, they may see stale data.

The replica is not permanently incorrect. It simply has not caught up yet.

Under normal conditions, replication lag may be very small. But during heavy load, network issues, or large write bursts, lag can grow significantly.

Replication lag creates an important user experience problem.

Imagine a user changes their username. The application confirms the update. They immediately refresh the page. But the read is sent to a replica that has not received the update yet. The old username appears. From the user's perspective, it looks like the update failed.

One common solution is read-after-write consistency. After a user performs a write, the system temporarily sends that user's reads to the primary. Once the replicas are expected to have caught up, reads can return to the replicas.

Another approach is to track replication progress and only use replicas that are known to contain the required update.

The exact implementation varies, but the goal is the same: once the system confirms a user's write, that user should ideally be able to read it immediately.

One of the most common uses of replication is scaling read-heavy workloads.

Suppose an application receives 1,000 writes per second but 50,000 reads per second. The primary may be able to handle the writes easily, but serving all 50,000 reads from the same machine could become expensive.

We could add several read replicas. The application still sends all writes to the primary. But read traffic is spread across the replicas. If there are five replicas, each may handle roughly one fifth of the read traffic, about 10,000 reads per second.

This works especially well for workloads where reads greatly outnumber writes.

But read replicas do not automatically increase write capacity. All writes may still need to pass through the primary.

Replication also helps when a database server fails.

Suppose the primary crashes. One of the replicas can be promoted and become the new primary. Applications then begin sending writes to that server instead. This process is called failover.

Some systems handle failover automatically. They monitor the primary, detect that it is unavailable, select a replica, promote it, and redirect traffic. Other systems require some manual coordination.

Failover sounds simple, but it introduces several difficult questions:

These problems become especially important in distributed systems.

One dangerous failure mode is called split brain.

Imagine the primary and replicas lose network connectivity with each other. The primary is still running. But the replicas cannot reach it.

If one replica assumes the primary has failed and promotes itself, the system may temporarily have two primaries. Some clients might send writes to the old primary. Others might send writes to the new one. Now two different versions of the database can evolve independently.

Reconciling those conflicting writes can be extremely difficult.

Replication systems use techniques such as quorum rules, leader election, fencing, and consensus protocols to reduce the chance of this happening.

The important idea is that failover is not simply about starting another database. The system must make sure there is only one authoritative writer when the architecture requires one.

Not every replication system uses a single primary. Some systems allow multiple database servers to accept writes. This is known as multi-primary or multi-leader replication.

For example, an application might have one writable database in the United States and another in Europe. Users in each region can write to their local database. The two databases then replicate changes to each other.

This can reduce write latency across regions.

But it creates a new problem. What happens if both regions update the same record at the same time? Now the system has a conflict.

Multi-primary replication therefore requires conflict detection and resolution. This makes the architecture significantly more complex.

Replication is not a replacement for backups.

Suppose someone accidentally deletes an entire table. That deletion may be immediately replicated to every replica. Now every copy contains the same mistake. The same can happen with corrupted data or an incorrect application update.

Production systems often need both.

Replication and sharding are also different.

Suppose we have 100 million users. With replication, several servers may each store all 100 million users. With sharding, each server may store only a portion of those users.

Large systems often combine both. The dataset is divided into shards, and each shard has its own replicas.

Replication is especially useful when:

But replication adds complexity. You need to think about lag, consistency, failover, replica health, and how writes are routed.

So before adding many replicas, understand the problem you are trying to solve. If the database is small, traffic is low, and occasional downtime is acceptable, a simpler architecture may be enough.

Database replication keeps copies of the same data on multiple servers. In the common model, one primary handles writes and sends its changes to replicas, which replay them on their own copies.

Replication improves availability, read scalability, and latency for users in different regions.

The key decision is when a write counts as successful. Synchronous replication waits for a replica and gives stronger durability at the cost of write latency. Asynchronous replication responds right away but can lose the latest writes if the primary fails, and it causes replication lag. Read-after-write consistency hides that lag from the user who just wrote.

Failover promotes a replica when the primary fails, but the system must avoid split brain, where two servers both accept writes. Multi-primary replication allows writes in several places at once, which brings conflicts that must be detected and resolved.

Replication does not replace backups, since mistakes are replicated too. It is also different from sharding: replication copies all the data, while sharding splits it. Large systems often use both.