Synchronous vs. asynchronous replication in real-time DBMSes

A modern real-time application or service needs to be fast, scalable, and available. Ensuring availability, and by extension durability and recoverability, requires replication across numerous servers that are geographically distant and introduces latency and scalability issues. This is the balancing act developers face: ensuring availability, consistency, and durability without hurting the core user experience. 

Getting the data replication balance right is a challenging exercise in compromises and prioritizations; the optimal approach is only possible with a thorough understanding of synchronous and asynchronous replication.

Note: Quotes featured in this article come from our Chief Technology Officer, Srini Srinivasan, and Chief Evangelist Srinivasan "Sesh" Seshadri's presentation at the 2025 SIGMOD conference in Berlin.

Why is replication important for real-time applications?

Servers break, power goes out, network connections are severed, and data gets corrupted. In short, systems fail. Replicating data across distributed, geographically dispersed servers keeps users' access alive and aids in the recovery of data that might otherwise have been lost.

" ...The only sure way to ensure that such services can survive catastrophic infrastructure failures is to deploy the DBMS as well as the applications themselves on multiple sites that are hundreds (or even thousands) of miles apart from each other."

Replication has always been the backbone of durable, available database systems, leading to the oft-cited IT aphorism: "If your data doesn't exist in three places, your data doesn't exist." Mission-critical systems cannot afford to go down or lose information.

These distributed networks are becoming more common for reasons beyond durability and availability, though. Distributed architectures, like edge computing and edge data models, are helping application developers with a range of benefits:

• Lower latencies, faster loading, and information retrieval

• High data availability

• Better UX and UI

• Easier legal and regulatory compliance

• Better data security

• Improved performance and demand scaling

These benefits don't come without challenges. Any data transfer takes a finite length of time, and the larger the distance it has to travel, the longer the transfer latency. Replicating data takes processing power, cutting into the application's CPU cycle budget, especially if any processing or transformations have to be performed before sending a copy. Maintaining multiple copies of data can grow expensive and create server bloat.

Synchronous and asynchronous replication are the two most common approaches to data replication, but they address the problem in different ways and have unique advantages and challenges. 

What is synchronous and asynchronous replication?

" …[Replication is] the process of copying and maintaining database objects, such as records or entire datasets, in multiple database servers for redundancy, availability, and performance…"

The two dominant approaches to data replication are synchronous and asynchronous. Though they have the same goals, they work and interact with the system as a whole in very different ways.

Synchronous replication definition

Synchronous replication is a data replication method with immediate or simultaneous replication of data across multiple storage media or servers. The process for synchronous replications can be modeled as follows:

1. The transaction is received by the primary server

2. Data is written to the primary server

3. The primary server sends a replication write to the replica/copy server and waits for a response

4. The replica writes the data and returns a confirmation of write to the primary

5. The primary moves to the next transaction only after the replica confirmation is received

In general, synchronous replication can be characterized as:

• Immediate

• Simultaneous

• Highly consistent

• Blocking

Asynchronous replication definition

Asynchronous replication is a data replication method with delayed or background replication of data across storage media or servers. The process for asynchronous replication usually looks something like:

1. The transaction is received by the primary server

2. Data is written to the primary server

3. The primary sends out a replication write to replica servers, then moves on to the next transaction

4. The replica receives the write request, writes the data, and sends a response

5. The primary receives the response and logs it, but has already moved on to other transactions

In general, asynchronous replication can be characterized as:

• Delayed

• Background

• Eventually consistent

• Nonblocking

Synchronous vs. asynchronous replication at a glance

Considerations for choosing synchronous vs. asynchronous replication

Both synchronous and asynchronous replication have benefits and challenges, often in direct opposition to each other. Selecting the right approach requires understanding and prioritizing application and user needs on a case-by-case basis.

To figure out which is right, consider the following:

Immediate vs. eventual consistency

Does the application need every cluster to contain identical data at the same time, or is some level of delay in consistency acceptable?

Freshness requirements/loss tolerance

How much data can the application afford to lose in the event of an incident? And will slightly stale data hurt the user experience or cause users or systems to make incorrect decisions?

Latency requirements

How long of a delay, both for transmission and processing, can the application tolerate?

Active-active/active-passive

Which servers update primary records? Are servers broken down into dedicated primaries and replicas, or are some set up to be both?

Filtering requirements

Does data get fully replicated at every cluster, or does any filtering need to take place between replication? This is especially important for modern edge compute patterns, as well as for security and compliance needs.

Intercluster or intracluster replication

Is data being replicated from one cluster to another, or is it being replicated between storage media within a single cluster?

Distribution needs

How far apart do the clusters need to be from one another? Do they need to be in different data centers, clouds, or regions?

When to use synchronous replication

The ideal use for synchronous replication is in applications where immediate consistency is an absolute requirement and latency is a secondary concern. These are mission-critical systems where a loss of even a few milliseconds of new data or tiny inconsistencies between nodes can result in significant consequences.

Synchronous replication is also often used within a single cluster to copy data across storage volumes or media. Because of the very short distances involved, transmission latency is not a high concern. However, synchronous replication still introduces some processing and I/O overhead even when transferring within a single server.

Benefits of synchronous replication:

• Strong, immediate compliance (ACID)

• Zero data loss, or recovery point objective (RPO) equal to zero, since data is copied immediately

• Reduced operational complexity since there's no need to deal with conflict resolution between inconsistent data

• Transactions have high integrity

• The system has very deterministic behavior and state. It's always possible to know what the state should be at any point in time and on any cluster based on the transaction history

Challenges of synchronous replication

"[Synchronous replication] would impact the write latency of transactions on a source cluster whose nodes (or racks) are stretched across geographically distant sites, as multiple replicas must be updated before confirming the write to the application."

• Synchronous replication can add significant latency, especially in widely distributed systems. Transmission takes time, as does the processing and I/O overhead of replication, and transaction processing stops until replication is confirmed by every cluster

• Higher coordination overhead takes processing power away from core functions, reducing throughput and maximum capacity

• Potential for availability issues if a replica is unavailable. Since processing pauses until confirmation is received and accepted, an out-of-commission replica could cause the entire system to wait for the entire length of a time-out interval

• More resource-intensive if latency is at all a concern, requiring higher-tier infrastructure to make performant

• Harder to scale across geographies

Best synchronous replication use cases

“Customers who prioritize consistency over availability… tolerate increased write latencies (up to 200ms)… our synchronous replication algorithm is used in these cases.”​

• Internal replication within a server, cluster, or data center

• Systems where consistency is more important than latency, for example, real-time financial clearinghouses and brokers

• Systems subject to close regulatory scrutiny or auditing requirements, like legal document management systems

• Systems with zero acceptable data loss, for example, real-time monitoring and logging of life support equipment or nuclear power plants

• Systems where latency is already not a concern, for example, systems that are set up for batch writes, ones that have minimal user interaction and high automation, or systems that are primarily read-only

When to use asynchronous replication

For many real-time consumer applications, perfect and immediate consistency is a much lower concern. For example, users playing a mobile game probably don't care that their high score might take a few seconds or even minutes to update on servers around the world. Instead, consumers want applications and services that are fast, can handle millions of connections without bogging down, and can be reached at any time.

Asynchronous replication is ideal for these kinds of applications. Because it's non-blocking and performs copying in the background, asynchronous replication can give end users the speed, availability, and throughput that consumers have come to expect.

Benefits of asynchronous replication

"Most high-performance consumer applications cannot tolerate the high write latencies required for synchronizing writes across far-apart sites… asynchronous replication… becomes the only practical option."

• Lower latencies: Asynchronous replication avoids the processing, writing, and confirmation delays that synchronous replication introduces. In massively geo-distributed deployment models, this could mean returning data to the user hundreds of nanoseconds faster.

• High throughput: The lack of locking and a reduction in coordination overhead result in more resources being available for primary processes and more transactions being processed in a time period.

• High availability and graceful failover: Not having to worry about every server being perfectly consistent allows applications using asynchronous replication to route users to the highest-performing cluster quickly.

• High scalability and high durability: Clusters can be distributed further apart when replica network delay is not a concern, making them less prone to regional outages and incidents.

• Better support for advanced replication strategies: Asynchronous systems allow for techniques like real-time per-replica filtering. This is an increasingly important part of complex edge computing approaches. The need for these strategies has spurred the development of new datatypes, like conflict-free replicated data types (CRDTs), that push out the cutting edge of distributed computing.

• Fast background incremental backup and fast cluster spin-up: Moving replication processes to the background and not worrying about consistency allows asynchronous replication to create backups for storage or for initializing new clusters quickly and automatically with no interruption in service.

Challenges of asynchronous replication

• Even if they all eventually converge, every server cannot be guaranteed to have exactly the same data at any given point in time.

• If a server with fresh data goes offline or becomes corrupted, backups on other servers may be left with stale data from an earlier state.

• Conflict resolution adds complexity in concurrent systems as multiple clusters try to modify the same base data in different ways.

• SLAs and contracting may be more complicated and require the negotiation of acceptable delays in consistency and data-loss windows.

• Operational complexity can increase due to more nuanced configuration and monitoring needs to ensure that issues in replication are identified and resolved quickly.

• Asynchronous replication can create difficulty in ensuring audit and compliance readiness or state guarantees.

Asynchronous replication use cases

"For fraud prevention, the AI model [that performs hundreds of reads within ~100 ms] must have access to recent behavioral data to enable timely action, making low-latency reads and writes essential."

• Systems where hyper-fast access and minimal latency are non-negotiable, such as algorithmic trading services or digital ad bidding

• Systems that prioritize high availability and need exceptional data and access resiliency, for example, emergency alert and dispatching systems

• Edge computing systems that need advanced filtering or the ability to place data as close to users as possible, like customer 360 systems

• High-volume/high-throughput systems that need to be able to handle millions of concurrent requests quickly, like fraud detection

• Use case example: Leading high-frequency trading (HFT) systems have tick-to-trade times of tens to low hundreds of nanoseconds — about 100,000,000 times faster than blinking. Modern FPGA/ASIC systems can go from receiving information to executing decisions in as few as four to five nanoseconds. They move so quickly that they often don't even bother parsing data into standard formats (like the Financial Information eXchange, or FIX), instead acting on native exchange binary.
  
  Adding even an extra 50 nanoseconds to processing time with synchronous replication can be the difference between a profitable trade and a loss. However, not replicating data can result in losing valuable data that provides an edge. Asynchronous replication allows these systems to protect data without cutting into profits.

Advanced approaches for asynchronous replication with Aerospike

Asynchronous replication has become the dominant mode for modern real-time database management systems (DBMSes) that serve modern real-time applications. Their focus on low latencies, high throughput, better scalability, and easier durability and distribution makes them a perfect match for current patterns and paradigms. 

But not all asynchronous replication systems are created equal. Some, like Aerospike's XDR, were co-designed and co-developed with core database processes to minimize overhead and optimize efficiency. Others were tacked on after the fact just to bring legacy database systems into the modern era, or to position limited datastores as full-featured databases.

XDR was built to support highly available, highly distributed, low latency systems like modern real-time applications (e.g., AdTech and fraud detection for financial services). Originally standing for "Cross Datacenter Replication," it's been updated over the years to support not just multiple clusters in multiple regions, but also multi-cloud and cross-cloud deployments.

The system was designed to operate in environments where a round-trip can take 70 to 200 nanoseconds or more, making synchronous applications infeasible. Latency was further reduced by tightly integrating replication approaches with the core Aerospike database process to minimize processing overhead and cut inter-process communication times. While it started as an instruction log like many other asynchronous replication solutions, for example, Redis' append-only file, that approach proved to be a poor fit due to slow recovery times, high storage requirements, and excessive I/O latency.

The Aerospike XDR system is a good case study in what an advanced, best-in-class replication system needs to be. These systems should offer at a minimum:

• The ability to efficiently "play back" a previous state using fast logic-like lookup tables rather than having to rebuild a state from executing instruction log entries one by one, e.g., Aerospike XDR's "rewind" feature

• Intelligent throttling and recovery that can detect lag, connection issues, or I/O buildups in real time and respond in a way that maintains availability without any increased risk of data loss

• Advanced conflict resolution options that maintain data integrity without adding excessive coordination overhead using techniques like CRDTs or per-bin convergence

• Variable ship times like ship-once-in-a-window or ship-all, and the ability to easily alter ship times on the fly or dynamically based on load, demand, and volume

• Filtering and transformations are baked into the replication process to allow for low-latency data transfers from a database of record out to edge clusters and vice versa

• Interoperability and support for replication across heterogeneous system architectures, e.g., replication from one cloud to another or across clusters running different hardware and software

• Support for common event-driven computing streaming connectors like Kafka and Pulsar, especially when sending data out from the database

Developers looking for a DBMS to support their real-time service should make sure that any system under consideration offers all of this functionality, and do so natively without needing kludgy workarounds with modules or third-party tools like proxies or translators.

Aerospike XDR performance: Benchmarking a best-in-class asynchronous replication system

An extensive list of requirements can make finding a DBMS more challenging, but the results are well worth it. In benchmarking XDR, Aerospike found:

• Processing overhead of less than a 3% increase in CPU utilization

• Incredibly short recovery times, with Rewind being able to recover 10 million records in 20 to 50 seconds

• Predictable, stable scaling behavior, with linear improvement moving from three to six clusters

To learn more about how Aerospike built XDR, and for more insights from the cutting edge of distributed data and replication, look for the presentation from our Chief Technology Officer, Srini Srinivasan, and Chief Evangelist, Srinivasan "Sesh" Seshadri, at the 2025 SIGMOD conference in Berlin.