What Is Database Replication?

A Database Replication is the process of maintaining multiple synchronized copies of the same database across different servers.

A Primary (Leader) database accepts write operations, while one or more Replicas (Followers) continuously receive and apply changes from the primary.

This allows multiple database instances to contain the same data while serving different workloads.

Most modern databases, including PostgreSQL, MySQL, MongoDB, and managed services such as Amazon RDS, provide built-in replication support.

Why Do We Need Database Replication?

Consider a Spring Boot e-commerce application that receives thousands of requests every second. Most requests retrieve product information, customer profiles, or order history, while relatively few modify data.

If a single database handles both read and write operations, it eventually becomes a bottleneck as traffic grows, increasing query latency and limiting scalability.

Database replication addresses this by allowing write operations to continue on the primary database while read operations are distributed across multiple replicas, significantly increasing read capacity.

          Application
               |
       +-------+-------+
       |               |
     Writes          Reads
       |               |
       v               v
   Primary DB     Replica DBs
                    |      |
                    v      v
               Replica  Replica

Replication also improves high availability and fault tolerance.

If the primary database becomes unavailable, a replica can be promoted to become the new primary, reducing downtime and improving overall system resilience.

Replicated data also provides an additional copy for backup and disaster recovery.

Replication Types

Database replication can be implemented using different architectures depending on the application's requirements for availability, read scalability, and write scalability.

The most common replication types are Primary-Replica Replication and Multi-Primary Replication.

Primary-Replica Replication

This is the most widely used replication model. A single Primary database accepts all write operations, while one or more Replicas receive copies of the changes and typically serve read requests.

             Application
                 |             
            Write Requests   
                 |                  
                 v                  
      +---------------------+      
      | Primary Database    |
      |      (Leader)       |
      +---------------------+
                 | 
          Replication
      +----------+----------+
      |                     |
      v                     v
+----------------+   +----------------+
|   Replica 1    |   |   Replica 2    |
|   (Follower)   |   |   (Follower)   |
+----------------+   +----------------+
        ^                     ^
        |                     |
        +----------+----------+
                   |
             Read Requests

This architecture is simple to manage and is commonly used with databases such as PostgreSQL, MySQL, and Amazon RDS.

Multi-Primary Replication

In Multi-Primary (also called Multi-Master) replication, multiple database instances can accept both reads and writes. Changes made on one primary are replicated to the others.

      +----------------+      Replication      +----------------+
      |   Primary A    |<--------------------->|   Primary B    |
      | (Read / Write) |                       | (Read / Write) |
      +----------------+                       +----------------+
               ^                                      ^
               |                                      |
               |                                      |
               +------------Replication---------------+
                              |
                              v
                     +----------------+
                     |   Primary C    |
                     | (Read / Write) |
                     +----------------+

This architecture improves write availability because applications can continue writing even if one primary becomes unavailable.

However, it introduces additional complexity such as conflict detection and conflict resolution when the same data is modified simultaneously on different nodes.

For this reason, multi-primary replication is less common than the primary-replica model.

Read Scaling

In a Primary-Replica architecture, write operations are directed to the primary database, while read operations can be distributed across one or more replicas.

As additional replicas are added, the system can handle a larger number of concurrent read requests without increasing the load on the primary database.

This makes replication particularly effective for applications where reads greatly outnumber writes, such as e-commerce websites, news portals, and content management systems.

How Replication Works

Suppose the application inserts a new customer into the database.

INSERT INTO customers(id, name) VALUES (101, 'John');

The transaction is first committed on the primary database. The replication mechanism then propagates the same change to each replica, keeping every copy of the database synchronized.

     +----------------------+
     |   Primary Database   |
     +----------------------+
                |
      Commit Transaction
                |
                v
          Replication
        +-------+-------+
        |               |
        v               v
 +---------------+ +---------------+
 |   Replica 1   | |   Replica 2   |
 +---------------+ +---------------+

Synchronous Replication

In Synchronous Replication, the primary waits until one or more replicas confirm that the transaction has been written before reporting success to the application.

         Application
               |
               v
     +----------------------+
     |   Primary Database   |
     +----------------------+
               |
         Commit Transaction
               |
         Replication
               |
      +--------+--------+
      |                 |
      v                 v
+---------------+ +---------------+
|   Replica 1   | |   Replica 2   |
+---------------+ +---------------+
               |
  Wait for Acknowledgement
               |
               v
        Return Success

This approach minimizes data loss because replicas remain synchronized with the primary.

However, write operations become slower because the primary must wait for replica acknowledgements before completing the transaction.

Every successful write is guaranteed to exist on both the primary and the configured replicas before the application receives a response.

Asynchronous Replication

In Asynchronous Replication, the primary immediately acknowledges the transaction after writing locally.

Replication occurs in the background without waiting for replicas.

         Application
               |
               v
     +----------------------+
     |   Primary Database   |
     +----------------------+
               |
        Return Success
               |
               v
   Background Replication
               |
               v
      +----------------+
      |    Replica     |
      +----------------+

This approach provides lower write latency and higher throughput.

However, if the primary fails before replicas receive the latest changes, recent transactions may be lost.

Many production systems choose asynchronous replication because it offers better write performance while providing acceptable consistency for most applications.

The application receives a faster response, but replicas may temporarily lag behind the primary.

Replication Lag

Since replication is not always instantaneous, replicas may temporarily contain older data than the primary.

This delay is known as replication lag.

                 Time
                  |
                  v

Primary Database          Replica Database
------------------        ------------------
Order Created             Not Yet Replicated
      |                          |
      |------ Replication ------>|
      |                          |
      |                    Order Available

Suppose a customer places an order and immediately requests the order history. If the application reads from a replica before replication completes, the newly created order may not yet appear.

Applications handling critical read-after-write scenarios often read directly from the primary database immediately after updates.

This temporary inconsistency is expected in asynchronous replication and is commonly known as eventual consistency.

Automatic Failover

Replication also improves application availability.

If the primary database becomes unavailable, one of the replicas can be promoted to become the new primary.

     +----------------------+
     |   Primary Database   |
     +----------------------+
               |
           Failure
               |
               v
     +----------------------+
     |   Replica Database   |
     +----------------------+
               |
          Promotion
               |
               v
     +----------------------+
     |    New Primary       |
     +----------------------+

Cloud platforms such as Amazon RDS automate this failover process, reducing downtime during infrastructure failures.

Applications typically reconnect through a database endpoint or proxy, allowing them to continue operating without changing the connection configuration.

Replication in PostgreSQL (Primary-Replica)

PostgreSQL uses Write-Ahead Logging (WAL) for replication.

Whenever a transaction modifies data, PostgreSQL first records the changes in the WAL before updating the actual data files.

The primary database continuously streams these WAL records to one or more replicas, which replay the changes in the same order to keep their data synchronized.

         Spring Boot
              |
       INSERT / UPDATE
              |
              v
   +----------------------+
   | Primary PostgreSQL   |
   +----------------------+
              |
     Generate WAL Record
              |
   Streaming Replication
      +-------+-------+
      |               |
      v               v
+---------------+ +---------------+
|   Replica 1   | |   Replica 2   |
|  Replay WAL   | |  Replay WAL   |
+---------------+ +---------------+

When an application performs a write operation, it is always sent to the Primary database.

       POST /orders
             |
             v
     +----------------+
     |  Spring Boot   |
     +----------------+
             |
             v
+------------------------+
| Primary PostgreSQL DB  |
+------------------------+

After the transaction commits, the generated WAL records are streamed to the replicas.

Read requests can then be routed to one of the replicas, allowing the primary database to focus on write operations.

      GET /products
            |
            v
    +----------------+
    |  Spring Boot   |
    +----------------+
          |
     Read Routing
     +----+----+
     |         |
     v         v
+------------+ +------------+
| Replica 1  | | Replica 2  |
+------------+ +------------+

This architecture allows PostgreSQL to scale read-heavy workloads while ensuring that all writes are processed by a single primary database.

Replication in Cassandra

Unlike PostgreSQL, which relies on a single primary database, distributed databases such as Apache Cassandra have no primary node. Every node is capable of handling both reads and writes.

Data is automatically replicated across multiple nodes according to the configured Replication Factor (RF).

      Spring Boot
           |
           v
+----------------------+
|  Cassandra Cluster   |
+----------------------+
    |        |       |      
    v        v       v      
+------+ +------+ +------+ 
|Node 1| |Node 2| |Node 3|
+------+ +------+ +------+

Suppose the replication factor is 3.

      Replication Factor = 3
               |
               v
        Customer Data
               |
      +--------+--------+
      |        |        |
      v        v        v
+--------+ +--------+ +--------+
| Node 1 | | Node 2 | | Node 3 |
+--------+ +--------+ +--------+

Each piece of data is stored on three different nodes. If one node becomes unavailable, the remaining replicas continue serving both read and write requests.

Unlike PostgreSQL, Cassandra does not require all writes to pass through a primary node.

The application can send a request to any Cassandra node. That node temporarily acts as the Coordinator Node for that request.

The coordinator forwards the write to the appropriate replica nodes based on the partition key and replication factor.

        Spring Boot
             |
             v
   +--------------------+
   |  Coordinator Node  |
   +--------------------+
        |      |      |
        |      |      |
        v      v      v
+--------+ +--------+ +--------+
| Node 1 | | Node 2 | | Node 3 |
+--------+ +--------+ +--------+

The coordinator waits for acknowledgements according to the configured Consistency Level. For example, using a consistency level of QUORUM, a write succeeds after acknowledgements are received from a majority of replicas.

Read requests follow a similar process. The coordinator contacts one or more replicas, retrieves the requested data, and returns the result to the application.

         GET /customers/100
                |
                v
      +--------------------+
      |  Coordinator Node  |
      +--------------------+
                |
      Read from Replicas
      +------+------+------+
      |         |          |
      v         v          v
 +--------+ +--------+ +--------+
 | Node 1 | | Node 2 | | Node 3 |
 +--------+ +--------+ +--------+
                |
                v
       Return Latest Value

Because there is no single primary database, Cassandra eliminates the write bottleneck found in traditional primary-replica architectures.

This enables horizontal scaling for both reads and writes, making Cassandra well suited for applications that require very high write throughput and high availability across multiple data centers.

The trade-off is that applications typically operate with eventual consistency, with consistency controlled through configurable consistency levels such as ONE, QUORUM, and ALL.

Replication Factor = 3

ONE      Node1
QUORUM   Node1 + Node2
ALL      Node1 + Node2 + Node3

Summary

Database Replication maintains multiple synchronized copies of a database to improve availability, fault tolerance, read scalability, and disaster recovery.

The two most common replication architectures are Primary-Replica, where a single primary handles writes and replicas serve read requests, and Multi-Primary, where multiple database instances can accept both reads and writes.

Replication can be synchronous for stronger consistency or asynchronous for lower write latency and higher throughput, with the trade-off of possible replication lag.

Traditional relational databases such as PostgreSQL typically use a Primary-Replica architecture, whereas distributed databases such as Apache Cassandra replicate data across multiple peer nodes to provide horizontal scalability, high availability, and fault tolerance.