Data replication

What is data replication?

Data replication is the practice of keeping the same data in more than one place and making sure the copies stay in step as the original changes. When a record is written to the main system, that change is passed on to one or more copies so they hold the same information. It is not a one-off export. A replicated copy tracks its source continuously, so it stays current instead of drifting out of date the moment it is made.

People reach for replication to answer three different needs, and it helps to keep them apart because they pull in different directions. The first is staying available: if the main database dies, a copy can take over. The second is speed for a spread-out audience: a copy in another region answers local users faster than a single database on the other side of the world. The third is read scaling: point reports and lookups at copies so the main system is left free to handle writes.

Synchronous versus asynchronous

The single biggest choice in replication is when the source considers a write finished, and it comes down to two options.

With synchronous replication, the main system waits. A write is not confirmed to the application until at least one copy has acknowledged that it also stored the change. Nothing is lost if the main system fails a second later, because the copy already has the write. The cost is speed: every write now waits for a round trip to the copy, so the copy has to be close by on the network for this to stay practical.

With asynchronous replication, the main system does not wait. It confirms the write immediately and sends the change to the copies just after. This keeps writes fast and lets copies sit far away, even thousands of kilometres, without slowing local users. The trade-off is a window of risk: if the main system fails before a recent write reaches the copy, that write is gone. The size of that window is the replication lag.

This trade-off maps directly onto the recovery targets used in disaster recovery. RPO, the recovery point objective, is how much recent data you can afford to lose. Synchronous replication gives an RPO of zero, since the copy is always caught up. Asynchronous replication gives an RPO equal to the lag at the moment of failure, from a fraction of a second to minutes depending on distance and load.

Who can write: master-replica and beyond

The other design question is which copies are allowed to accept writes.

The common arrangement is single-leader, also called master-replica or primary-replica. One system, the leader, takes all the writes. The others are followers that receive the leader's changes and serve reads only. This is easy to reason about because there is one authoritative copy and no argument over what the current value is. A read replica, the standard offering from managed databases, is exactly this: a follower you send read queries to so the leader is spared the load.

The alternative is to let more than one copy accept writes, either several leaders or a leaderless design where any copy will take a write. This removes the single write bottleneck and survives the loss of a write node, but it introduces conflicts: two copies can change the same record at the same time, and the system needs a rule to decide who wins. That extra complexity is why most teams stay with single-leader until they have a concrete reason not to.

Where you meet replication

• High availability. A standby copy is kept ready so that if the primary fails, service continues with little or no interruption.

• Disaster recovery. A copy in a separate region survives a data centre outage or a regional problem that takes the primary offline entirely.

• Read scaling. Reporting queries, dashboards, and search run against read replicas, leaving the primary to handle transactions.

• Feeding a warehouse. Replicating operational data into a data warehouse keeps analytics current without hammering the production database. Change data capture is a light form of this, streaming each insert, update, and delete as it happens rather than copying whole tables.

What to watch out for with data replication

Replication lag causes stale reads. With asynchronous replication a follower is always slightly behind. A user who writes a change and then immediately reads from a replica can see the old value and think the save failed. If a workflow needs its own writes read back straight away, send those reads to the leader.

Replication is not a backup. A bad delete or a corrupting bug is faithfully copied to every replica within seconds. Replication protects against a machine dying, not against a mistake in the data. You still need real backups you can restore from a point in time.

Failover is a decision, not a reflex. Promoting a replica to leader when the old leader has not truly failed can leave two systems both accepting writes, which corrupts data. Getting failover right, and testing it, is harder than turning replication on.

Copies cost money and attention. Every replica is storage, compute, and network you pay for, plus one more thing to monitor and patch. Replicate for a reason you can name, not by default.