What is data replication?

Replication is the mechanism that keeps multiple copies of the same data synchronized across different nodes, so a node's failure or excessive load does not stop the system. Two opposite strategies exist. Synchronous replication confirms a write only after at least one other copy has received it: no data loss when it is the primary alone that fails, at the cost of higher latency on every write, because the client waits for a remote node's confirmation. Asynchronous replication confirms immediately and propagates the change a moment later: fast writes, but a window in which the primary node can lose data not yet reached by the replicas if it fails at that moment. The most common topology is primary-replica, with a single node accepting writes and the others read-only; some systems instead adopt multi-primary, where several nodes accept writes in parallel and an explicit conflict-resolution rule is needed when two nodes modify the same data almost simultaneously.

The delay you pay for, and the distance that worsens it

The practical cost of asynchronous replication is called replication lag: the time between a write on the primary and its arrival on a replica. It has a direct application consequence: a user who writes data and reads it back right away, if the read lands on a replica a few hundred milliseconds behind, does not find it, or finds the previous version, like a cart that appears to empty right after an order is confirmed. Quorum, in multi-primary or distributed systems, decides how many copies must confirm a write before the operation counts as valid: a small quorum is fast and stays writable even with several nodes down, but offers weaker guarantees on consistency and durability; a larger one is safer on both, at the cost of more latency and a lower threshold of tolerated failures. When replication is geographic, across continents, the constraint stops being purely an engineering one: Ireland and Virginia are about 5,500 kilometers apart, which at the speed of light in fiber sets a floor of roughly 55 milliseconds for a round trip, before routing and equipment are counted at all. It is a physical limit no software removes.

An enterprise example

A bank moving account balances to a multi-region cluster, to guarantee continuity even if an entire data center goes offline, almost always chooses synchronous replication on the smallest quorum that tolerates one failure, accepting a few extra milliseconds of latency on every transfer rather than ever losing a confirmed transaction. An e-commerce platform replicating its product catalog across regions chooses the opposite: asynchronous replication, because a price updated one second late causes no harm, while synchronous latency on every catalog read would kill response times. The same platform can use different strategies for different data, and the mistake to avoid is applying the most expensive regime to everything.

Why it matters for decision makers

Replication is the mechanism durability and availability rest on, but the two do not coincide: data can be durable, written to multiple copies that survive one node's failure, and at the same time temporarily unavailable for consistent reads across all of them, because of the lag. Confusing the two properties leads to promising continuity objectives the chosen architecture cannot support: the choice between synchronous and asynchronous replication, between primary-replica and multi-primary, has to be decided together with recovery time and recovery point objectives, not after. An RPO close to zero calls for synchronous or near-synchronous replication; one measured in hours is fine with asynchronous replication. When the goal is not the operational database's own continuity but feeding analytics or other systems, the answer is often a read replica or change data capture, not another layer of synchronous replication.