What Is Data Replication?

Almost every serious integration problem I have worked on eventually comes down to the same quiet question: where does this data live, and how many copies of it are there? Data replication is the discipline of answering that question deliberately rather than by accident. It is the practice of maintaining copies of the same data across multiple databases, servers or locations, and keeping those copies in agreement as the data changes. Replication is one of the load-bearing techniques inside the broader picture of how systems exchange data, and if you want the full map of that landscape, start with the enterprise system integration pillar, then come back here for the deep dive on this one building block.

The message up front: replication is not a feature you switch on and forget. Every replication design is a choice about where you are willing to accept latency, staleness or the risk of losing recent writes. Make that choice on purpose, matched to what the data is for, and replication is one of the most powerful tools in the integration toolkit. Make it by default and it becomes the source of your most confusing production incidents. For the wider context of how this fits with everything else, keep the integration pillar open alongside this guide.

1. What data replication is

Data replication is the process of copying data from a source database or store to one or more destinations, and then keeping those destinations up to date as the source changes. The source is usually called the primary (or leader, or master in older terminology), and the copies are called replicas (or followers, or standbys). The primary accepts writes. The replicas receive a stream of those changes and apply them to their own copy so that, ideally, every replica ends up holding the same data as the primary.

The important word in that description is "ongoing". Replication is not a one-time copy. Taking a single dump of a database and restoring it somewhere else is a copy, not replication. Replication is the continuous relationship: the replica subscribes to the primary's changes and applies them indefinitely, so the two stay aligned as the data evolves. That ongoing flow of changes is what distinguishes replication from a backup or a one-off export, and it is the reason replication introduces its own set of concerns around ordering, lag and consistency that a static copy never has to think about.

Replication operates at different granularities depending on the technology. Some systems replicate at the level of physical storage blocks (physical or block-level replication), shipping the raw changes to the on-disk data files. Others replicate logically, capturing the individual row changes or SQL statements and replaying them on the replica (logical replication). The logical approach is more flexible, since replicas can differ in structure and even in database version, while the physical approach is typically faster and simpler but requires the replica to be a near-identical clone. Both are replication; they simply capture the changes at different layers.

2. Why replicate: availability, read scaling, disaster recovery, locality

Nobody replicates data for its own sake. Replication always exists to buy one or more of four specific benefits, and being clear about which one you are actually after shapes every downstream decision.

• Availability and failover: if the primary database fails, a replica that already holds an up-to-date copy of the data can be promoted to take over, often in seconds. Without a replica, a primary failure means downtime until the machine is repaired or a backup is restored, which can be minutes or hours. With a warm replica standing by, the same failure becomes a brief blip. High availability is the single most common reason enterprises replicate.
• Read scaling: a single database can only serve so many queries per second before it saturates. Because most workloads read far more than they write, you can spread read traffic across several replicas while all writes still go to the primary. Reporting dashboards, search pages and analytics can hit replicas, leaving the primary free to handle the writes. This is one of the cheapest ways to scale a read-heavy system without re-architecting it.
• Disaster recovery: keeping a replica in a physically separate data centre or region means that if an entire site is lost to fire, flood, power failure or a regional cloud outage, a current copy of the data survives elsewhere. Disaster recovery replication is about geography: the copy has to be far enough away that whatever destroys the primary cannot also destroy the replica.
• Data locality: users in Abu Dhabi and users in Frankfurt cannot both be close to a single database. Placing a replica in each region lets local users read from a nearby copy, cutting the round-trip latency that a single central database would impose on the far-away half of your users. For global applications, locality replication is what makes the experience feel fast everywhere rather than fast in one place and sluggish everywhere else.

These four reasons often overlap. A single well-placed replica can provide failover capacity, absorb reporting reads, serve as a disaster-recovery copy, and sit close to a regional user base all at once. But when they conflict, and they do, you have to know which one is primary. A disaster-recovery replica in another region will always lag more than a same-rack failover replica, so if you need both, you usually need two different replicas configured differently. Naming the goal keeps you from silently trading away the benefit you cared about most.

3. How replication works

Mechanically, almost all replication follows the same shape. The primary records every change it makes to the data in an ordered log. In many databases this is called the write-ahead log, the transaction log, or the binary log. Every insert, update and delete lands in that log in commit order. Replication then ships this log to each replica, and each replica replays the changes in the same order, reconstructing the same state the primary reached.

The subtle and important variable is when the primary considers a write complete relative to the replicas receiving it. In a synchronous replica, the primary waits for the replica to confirm it has received (or applied) the change before telling the client the write succeeded. In an asynchronous replica, the primary confirms the write to the client immediately and streams the change to the replica afterwards, without waiting. That single timing decision is the root of the entire synchronous-versus-asynchronous trade-off, and the diagram below shows both paths from one primary at once.

Read the diagram as one write following two fates. The client sends a write to the primary. The primary must get the change onto Replica A (synchronous) and wait for its acknowledgement before it confirms the commit back to the client, which is why that green acknowledgement arrow sits directly on the commit path. Meanwhile the primary streams the same change to Replica B (asynchronous) without waiting, so Replica B catches up a moment later. The synchronous replica is durable and current at the cost of every write waiting on the network round-trip; the asynchronous replica is cheap and fast at the cost of being a little behind. Everything else in replication design is a variation on this one picture.

4. Replication types

Beyond the timing question, replication technologies differ in what and how they copy. The three classic patterns, most familiar from the SQL Server world but conceptually general, are snapshot, transactional and merge replication. Layered on top of any of them is the synchronous-versus-asynchronous choice covered above. The table sets them side by side.

The two dimensions are independent. Transactional replication can run synchronously or asynchronously; a snapshot job is effectively asynchronous by nature. In practice most enterprise setups combine a transactional or physical stream with an asynchronous timing model for remote replicas and a synchronous one for a nearby standby. Naming your type along both axes, the pattern and the timing, is the clearest way to describe what you have actually built.

5. Synchronous versus asynchronous

This is the trade-off worth internalising because it never goes away. With synchronous replication, the primary does not tell the client a write succeeded until at least one replica has acknowledged it. The payoff is durability: if the primary dies the instant after a commit, the acknowledged replica already holds that write, so promoting it loses nothing. The cost is latency. Every write now includes a network round-trip to the replica, so the further away the replica is, the slower every write becomes. Put a synchronous replica in another continent and you have made every write pay the speed-of-light tax on that distance, which is why synchronous replicas are almost always kept close, in the same data centre or availability zone.

With asynchronous replication, the primary commits and responds to the client immediately, then forwards the change to replicas in the background. Writes stay fast regardless of how far away the replicas are, which is exactly what you want for a disaster-recovery copy in a distant region. The cost is a window of vulnerability: if the primary fails before a recent change has reached the replica, that change is lost, because the client was already told it succeeded. The replica is also always slightly behind, so a read served from it can be stale by whatever the current lag happens to be.

The honest limitation: there is no configuration that gives you zero write latency, zero data-loss risk and a globally distant replica all at once. Physics forbids it. Synchronous buys durability with latency; asynchronous buys speed and distance with a small data-loss window. Anyone who tells you their replication is both instant and lossless across regions is either confused or selling something. Decide which risk you can tolerate for this specific data, then pick accordingly, and it is entirely normal to run both models against the same primary for different purposes.

A common and sensible pattern is a hybrid: a synchronous replica nearby for zero-data-loss failover, plus one or more asynchronous replicas in other regions for disaster recovery and locality. The nearby synchronous copy protects your recent writes; the distant asynchronous copies protect you from losing the whole site and put data close to remote users. This is precisely the arrangement drawn in the diagram earlier, and it is the default I reach for on any system where both durability and geographic resilience matter.

6. Replication versus synchronization versus backup

These three terms get used interchangeably and they should not be, because they solve different problems and confusing them leads to real gaps in a design.

Replication is generally one-directional and continuous: a primary pushes its changes to replicas that are treated as copies, not as independent authorities. The replicas usually accept reads but not writes (except in multi-master or merge setups). The goal is to have the same data in more than one place for availability, scale and locality.

Synchronization is typically bidirectional and reconciliatory: two or more systems each hold their own data, each may change it, and the job is to make them agree by exchanging changes in both directions and resolving conflicts. Where replication has a clear source of truth, synchronization often has two peers that both consider themselves authoritative and must be brought into alignment. If you want the full treatment of that distinction, the data synchronization guide covers it directly.

Backup is point-in-time and for recovery: a copy of the data as it stood at a moment, retained so you can restore it after a mistake, corruption or ransomware event. The critical difference is that replication faithfully copies everything, including your errors. If someone drops a table on the primary, replication dutifully drops it on every replica within seconds. A backup from before the mistake is what saves you. This is why replication is not a backup, no matter how many replicas you have, and why any serious system needs both: replication for availability and backups for recoverability.

The distinction that saves you: replication protects against a machine dying. Backup protects against a change you regret. They are not substitutes. A replicated system with no backups will replicate your accidental deletion instantly and leave you nowhere to recover from; a backed-up system with no replication will survive a disk failure only after a slow restore. Mature designs run both, deliberately.

7. Consistency and replication lag

The moment you have more than one copy of the data, you have to reason about consistency: do all copies show the same value at the same time? With asynchronous replication the answer is a firm "not always", and the gap has a name, replication lag. Lag is the delay between a change committing on the primary and that change appearing on a replica. Under light load it can be milliseconds; under heavy write bursts, network congestion or a slow replica, it can stretch to seconds or worse.

Replication lag produces the classic and genuinely confusing bug: a user updates their profile, the write commits on the primary, the app immediately reads back from a replica that has not yet received the change, and the user sees their old data and assumes the save failed. Nothing is broken; the read simply raced ahead of replication. This is the difference between strong consistency, where every read reflects the latest write, and eventual consistency, where replicas converge on the correct value given enough time but may briefly disagree. Asynchronous replicas are eventually consistent by design.

There are well-known ways to manage this. You can route reads that must be current to the primary rather than a replica. You can use "read your own writes" techniques, where a user who just wrote is served their subsequent reads from the primary for a short window. You can monitor lag and stop serving reads from a replica that has fallen too far behind. What you cannot do is pretend the lag is not there. Any application reading from asynchronous replicas has to be designed with the knowledge that a replica may be briefly stale, and the places where staleness is unacceptable must be routed to a synchronous copy or the primary. Change-based techniques that make this replication stream visible and usable, such as capturing the change log directly, are covered in the change data capture guide and, for the SQL Server specifics, the CDC in SQL Server walkthrough.

8. When to use replication

Replication earns its place whenever one of the four benefits is genuinely needed and the trade-offs are acceptable. The situations where I reach for it:

• You need high availability. A business system that cannot tolerate long outages needs a warm replica ready to be promoted. This is the most common driver, and even a single asynchronous standby dramatically shortens recovery from a primary failure.
• Your reads dwarf your writes. Reporting-heavy, dashboard-heavy or search-heavy workloads can offload their reads to replicas and relieve the primary cheaply, long before you need to consider sharding or a bigger machine.
• You need to survive losing a site. Any system where a regional outage would be a serious business event needs an asynchronous replica in another region as a disaster-recovery copy that is always current to within seconds.
• Your users are geographically spread. Global applications place regional read replicas near their users to cut latency, so a user in the Gulf and a user in Europe both read from something close by.
• You are feeding downstream systems. Analytics warehouses, search indexes and integration hubs are often fed from a replica or from the replication stream itself, so heavy downstream reads never touch the production primary. This is where replication and integration meet directly, and platform-specific integration mechanics, such as the ones in the Business Central APIs and integrations guide, often sit on top of exactly this kind of replicated or change-fed data.

Equally, know when not to bother. A small internal tool with a handful of users, light traffic and a tolerance for occasional short downtime does not need replication; a good backup regime covers it. Replication adds real operational weight: more machines, lag to monitor, failover logic to test, and consistency edge cases to design around. Add it when a specific benefit justifies that weight, not because it feels like good practice in the abstract. The right question is never "should we replicate" in general, it is "which of the four benefits do we need for this data, and is the trade-off worth it here."

9. References

The concepts in this guide are standard across the database and distributed-systems literature. For deeper study, these are the sources I consider authoritative and vendor-neutral enough to trust:

• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly). Chapter 5, "Replication", is the clearest single treatment of leaders, followers, synchronous versus asynchronous, and replication lag that I know of.
• PostgreSQL documentation, "High Availability, Load Balancing, and Replication", covering streaming replication, synchronous commit and logical replication in a real system.
• Microsoft SQL Server documentation, "SQL Server Replication", which defines snapshot, transactional and merge replication as used in this guide.
• MySQL Reference Manual, "Replication", covering binary-log-based replication and semi-synchronous replication.
• Microsoft Learn, "Business Central API and integration" documentation, for how a specific ERP exposes data to the downstream systems discussed above.

Final thoughts

Data replication is one of those techniques that looks simple from the outside, copy the data, keep it fresh, and reveals its depth the moment you run it in production. The mechanics are consistent everywhere: a primary logs its changes, replicas replay them in order, and one timing decision, wait for the replica or do not, sets the whole character of the system. Everything hard about replication flows from having more than one copy: lag, staleness, the difference between strong and eventual consistency, and the uncomfortable fact that replication copies your mistakes as faithfully as your good data.

The practitioner's discipline is to design replication for the specific benefit you need. Availability, read scaling, disaster recovery, locality, each pulls the design in a slightly different direction, and the synchronous-versus-asynchronous choice is where those directions get resolved. Keep replication distinct from synchronization and backup in your own head, route the reads that must be current away from lagging replicas, and always pair replication with real backups. Get those few things right and replication does exactly what it promises: the same data, in the right places, available when you need it. For where this fits in the wider integration picture, the enterprise system integration pillar ties it back to everything else.

Related reading: Enterprise system integration explained, What is data synchronization, What is change data capture, Change data capture in SQL Server, Business Central APIs and integrations.