What Is Replication, and Why Do Databases Need It?

Data replication means storing the same data in more than one place—across multiple nodes, machines, or regions. A content delivery network (CDN), for example, copies content to multiple geographic locations. This improves availability because other nodes remain accessible if one fails, while also reducing latency by bringing data closer to users.

You can think of replication as taking colocation one step further. Colocation reduces latency by placing data closer to where it is needed. Replication creates copies in multiple locations, allowing each region to respond using a nearby copy and thereby serve requests faster.

Common Data Replication Strategies from a Latency Perspective

In practice, replication generally follows one of three strategies: single-leader, multi-leader, or leaderless replication. Let's look at how each model affects latency.

In single-leader replication, one designated node—the leader—accepts all client writes. Other nodes receive updates from the leader to keep their copies current. This architecture is relatively straightforward, but it can introduce latency.

Because every write must reach the leader, an application with its leader in the United States requires users in Asia to send their writes all the way there. Replica databases on other Asian nodes must then wait for the data to return from the United States before they can catch up. In a global system, this physical distance can significantly increase latency.

Multi-leader replication extends the single-leader model by introducing several leaders. Each can accept writes and synchronize them with the others. It is uncommon within a single data center because it adds complexity—for example, the system must resolve conflicting writes received by different leaders—and machines in the same data center are already physically close together. Across multiple data centers, however, this model can substantially reduce latency.

Returning to the previous example, users in Asia no longer need to send writes to a leader in the United States. They can write directly to a leader in Asia, while users in the United States and Europe can do the same in their local regions. Avoiding long-distance transmission during writes can reduce latency considerably.

Of course, lower latency comes at a cost. More leaders mean more complex write conflicts, cross-region delays, and recovery and resynchronization procedures after failures.

With leaderless replication, every node has equal status and can accept writes. This is attractive from a latency perspective because clients can write to the nearest available node instead of locating a specific leader. However, accepting writes on any node also makes maintaining consistency across nodes more difficult to implement.

The Tradeoff Between Consistency and Latency

Replication itself is easy enough to understand. The difficult part is keeping multiple copies synchronized across regions. This raises consistency questions: after a value is written, will it immediately appear in every replica? If not, how long will it take?

Every model, from single-leader to leaderless replication, makes tradeoffs between consistency and latency. Different consistency guarantees impose different latency costs. If users can read data only after every replica has synchronized, latency increases. Reducing latency, on the other hand, may require accepting that some replicas have not yet received the latest update.

There is no universally correct answer. The right tradeoff depends on the situation. You need to ask whether faster reads and writes are worth the possibility of serving stale data, or whether users must always see the latest data even if reads become slower.

So far, we have discussed the tradeoff between consistency and latency in broad terms. In reality, consistency is more of a spectrum, ranging from stronger to weaker guarantees. Two of the most common models are strong consistency and eventual consistency.

Strong consistency ensures that even when many replicas exist, the application behaves as though there were only one copy of the data. Every operation appears to act on that same copy. Users do not need to know that multiple replicas exist, and the application does not need to worry about reading stale data. The tradeoff is higher latency: the system must coordinate to confirm that replicas have been updated and retry when something goes wrong. Those round trips take time.

Eventual consistency does not guarantee that every replica is identical at any given moment. Instead, it guarantees that their states will converge eventually. A network outage, for example, might leave one replica behind and cause users to see stale data. Eventual consistency tolerates this temporary state; strong consistency does not.

Eventual consistency may sound less desirable when the goal is to show users the latest data at all times. Yet it is a common choice for low-latency systems because it avoids expensive coordination across nodes. Rather than confirming multiple replicas during every write, the system can complete the write locally and synchronize the remaining replicas later.

For example, when a write occurs in Asia, an eventually consistent system can return success as soon as the Asian replica is updated. A strongly consistent system must complete the required coordination with replicas in other regions before confirming the write, adding one or more cross-region network round trips. From the user's perspective, the eventually consistent approach can be much faster.

Support ExplainThis

If you found this content valuable, please consider supporting our work with a one-time donation of whatever amount feels right to you through this Buy Me a Coffee page.

Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.