Synchronous vs Asynchronous Replication — Database Scaling

The most important replication decision is whether the primary should wait for the secondary before confirming a write.

The most important replication decision is whether the primary should wait for the secondary before confirming a write.

Synchronous Replication → primary waits for required replica acknowledgement.
Asynchronous Replication → primary can acknowledge the write before the replica has applied it.

1. Synchronous Replication

The simplified flow is:

sequenceDiagram
    participant API as Application
    participant P as Primary
    participant S as Secondary

    API->>P: INSERT Order
    P->>S: Replicate Change
    S-->>P: Acknowledgement
    P-->>API: COMMIT Success

The write is considered complete only after the required secondary has acknowledged the replication operation, depending on the database's configured synchronous-commit semantics.

Advantages

Stronger durability guarantees.
Lower potential data loss during failover.
Useful for critical data where durability is important.

Trade-Off

The primary may have to wait for the secondary, so network latency and secondary performance can increase write latency.

2. Asynchronous Replication

The primary can acknowledge the application before the secondary has applied the change.

sequenceDiagram
    participant API as Application
    participant P as Primary
    participant S as Secondary

    API->>P: INSERT Order
    P-->>API: Success

    P->>S: Replicate Change
    S->>S: Apply Change

This can provide lower write latency, but the secondary may temporarily be behind.

Complete Example — What Happens During Failure?

Suppose the application creates:

OrderId = 1001
Amount = 5000
Status = Paid

Synchronous

sequenceDiagram
    participant API
    participant P as Primary
    participant S as Secondary

    API->>P: INSERT Order 1001
    P->>S: Replicate Order 1001
    S-->>P: Acknowledged
    P-->>API: Success

    Note over P,S: Both have the committed change

If the primary fails after the successful acknowledgement, the required synchronous secondary has the replicated change according to the configured synchronous-commit guarantees.

Asynchronous

sequenceDiagram
    participant API
    participant P as Primary
    participant S as Secondary

    API->>P: INSERT Order 1001
    P-->>API: Success

    Note over P,S: Replication still pending

    P->>P: FAILURE

    S->>S: Become New Primary

Depending on when the failure occurred, Order 1001 may not have reached the secondary yet.

SQL Server Example

SQL Server Always On Availability Groups are commonly used to provide high availability and database replication between replicas.

The following example shows the important configuration concept:

ALTER DATABASE [OrderDb]
SET HADR AVAILABILITY GROUP = [OrderAG];

The actual Always On configuration involves creating an availability group, configuring replicas, endpoints, databases, and replica synchronization settings.

SQL Server — Synchronous Commit Configuration

In an Always On Availability Group, a secondary replica can be configured for synchronous commit.

ALTER DATABASE [OrderDb]
SET HADR AVAILABILITY GROUP = [OrderAG];

The availability replica configuration determines whether the replica uses synchronous or asynchronous commit.

For example, conceptually:

-- Conceptual configuration

PRIMARY
    Availability Mode = SYNCHRONOUS_COMMIT

SECONDARY
    Availability Mode = SYNCHRONOUS_COMMIT

In production, these settings are configured at the availability-replica level rather than by simply running the above database statement.

SQL Server — Inspect Replica Configuration

You can inspect Always On replica configuration using SQL Server DMVs.

SELECT
    ar.replica_server_name,
    ar.availability_mode_desc,
    ar.failover_mode_desc,
    ars.role_desc,
    ars.connected_state_desc,
    ars.synchronization_health_desc
FROM sys.availability_replicas ar
JOIN sys.dm_hadr_availability_replica_states ars
    ON ar.replica_id = ars.replica_id;

Example output:

replica_server_name | availability_mode_desc | failover_mode_desc | role_desc | connected_state_desc | synchronization_health_desc
--------------------|------------------------|--------------------|-----------|----------------------|----------------------------
SQL-PRIMARY         | SYNCHRONOUS_COMMIT     | AUTOMATIC           | PRIMARY   | CONNECTED            | HEALTHY
SQL-SECONDARY       | SYNCHRONOUS_COMMIT     | AUTOMATIC           | SECONDARY | CONNECTED            | HEALTHY

SQL Server — Asynchronous Configuration

A secondary can instead use asynchronous commit:

replica_server_name | availability_mode_desc
--------------------|------------------------
SQL-PRIMARY         | SYNCHRONOUS_COMMIT
SQL-DR              | ASYNCHRONOUS_COMMIT

This is commonly useful when the secondary is geographically distant from the primary and waiting for it on every write would add significant latency.

Complete SQL Server Demonstration — Detecting Synchronization State

Run the following query on the SQL Server hosting the Availability Group:

SELECT
    DB_NAME(drs.database_id) AS DatabaseName,
    ar.replica_server_name,
    ars.role_desc,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.redo_queue_size,
    drs.last_commit_time
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar
    ON drs.replica_id = ar.replica_id
JOIN sys.dm_hadr_availability_replica_states ars
    ON ar.replica_id = ars.replica_id
WHERE DB_NAME(drs.database_id) = 'OrderDb';

Example output:

DatabaseName | replica_server_name | role_desc | synchronization_state_desc | synchronization_health_desc | log_send_queue_size | redo_queue_size
-------------|---------------------|-----------|----------------------------|-----------------------------|---------------------|----------------
OrderDb      | SQL-PRIMARY         | PRIMARY   | SYNCHRONIZED               | HEALTHY                     | 0                   | 0
OrderDb      | SQL-SECONDARY       | SECONDARY | SYNCHRONIZED               | HEALTHY                     | 0                   | 0

If the secondary is behind, you may see values such as:

DatabaseName | replica_server_name | role_desc | synchronization_state_desc | synchronization_health_desc | log_send_queue_size | redo_queue_size
-------------|---------------------|-----------|----------------------------|-----------------------------|---------------------|----------------
OrderDb      | SQL-PRIMARY         | PRIMARY   | SYNCHRONIZING              | NOT_HEALTHY                 | 250000              | 0
OrderDb      | SQL-SECONDARY       | SECONDARY | SYNCHRONIZING              | NOT_HEALTHY                 | 250000              | 120000

The queue sizes indicate that the secondary has work to catch up on.

Simple SQL Server Test Without Always On

You can also understand the consistency problem with two SQL Server sessions.

Session 1:

CREATE TABLE Accounts
(
    AccountId INT PRIMARY KEY,
    Balance DECIMAL(18,2)
);

INSERT INTO Accounts
VALUES (1, 1000.00);

BEGIN TRANSACTION;

UPDATE Accounts
SET Balance = 500.00
WHERE AccountId = 1;

-- Do not COMMIT yet

Session 2:

SELECT *
FROM Accounts
WHERE AccountId = 1;

With normal Read Committed behavior, Session 2 does not simply read Session 1's uncommitted change. It waits or uses the database's configured row-versioning behavior if enabled.

Now Session 1 commits:

COMMIT;

Session 2 can then see the committed value:

AccountId | Balance
----------|--------
1         | 500.00

This demonstrates an important distinction: transaction isolation controls what transactions see; replication controls how committed changes are propagated between database nodes.

Synchronous vs Asynchronous

Feature	Synchronous	Asynchronous
Primary waits for required replica acknowledgement	Yes	No
Write latency	Can be higher	Usually lower
Replica lag	Can be minimized under healthy conditions	Can be higher
Potential data loss on failover	Lower under configured synchronous guarantees	Possible for changes not yet replicated
Cross-region use	Possible, but latency can be significant	Often more practical for distant regions

How to Choose?

flowchart TD
    A[Choose Replication Mode] --> B{How Important Is Immediate Durability?}

    B -->|Very High| C[Synchronous Commit]
    B -->|Lower Latency Preferred| D[Asynchronous Commit]

    C --> E[Higher Write Coordination]
    C --> F[Lower Potential Data Loss]

    D --> G[Lower Write Latency]
    D --> H[Replication Lag Possible]

For a critical financial system, stronger durability requirements may justify synchronous replication within an appropriately close failure domain.

For a geographically distant disaster-recovery replica, asynchronous replication may be preferred because cross-region network latency should not necessarily delay every production write.

Important Interview Point

Do not simply say:

Synchronous = Good
Asynchronous = Bad

Instead explain the trade-off:

Synchronous
→ stronger durability coordination
→ potentially higher write latency

Asynchronous
→ lower write latency
→ possible replication lag
→ possible loss of not-yet-replicated changes during failover

Interview Scenario

Interviewer: Your primary database is in India and your disaster-recovery database is in the US. Would you always use synchronous replication?

Answer: Not necessarily. Cross-region synchronous replication can add significant network latency to production writes. I would evaluate the application's RPO, RTO, latency requirements, and durability requirements. A common architecture may use strong/synchronous protection within a nearby high-availability setup and asynchronous replication to a distant disaster-recovery region.

Common Interview Questions

What is synchronous replication?
What is asynchronous replication?
What is the main difference between them?
Why can synchronous replication increase write latency?
What happens if an asynchronous replica is behind when the primary fails?
When would you use synchronous replication?
When would you use asynchronous replication?
How does SQL Server Always On support synchronous and asynchronous commit?
How do you monitor SQL Server replication/synchronization health?

Key Takeaways

Synchronous → primary coordinates with required replicas before completing the write according to configured semantics.
Asynchronous → primary can complete the write without waiting for the replica to apply it.
Synchronous can provide stronger durability guarantees but may increase latency.
Asynchronous generally provides lower write latency but introduces replication lag.
SQL Server Always On Availability Groups support synchronous and asynchronous commit modes.
The correct choice depends on RPO, RTO, latency, availability, and consistency requirements.

Conclusion

The simplest way to remember this concept is:

Synchronous → Wait for replication → Stronger durability coordination → More latency

Asynchronous → Don't wait → Lower latency → Replication lag / potential data loss during failover

Articles categories

Projects categories

Cheatsheets categories

Videos categories

eBooks categories

Latest articles