Database Replication

If our database server dies, all our data is gone. If traffic spikes, one server can’t handle all the reads. Replication solves both problems by keeping copies of our data on multiple servers.

What Is Replication?

Replication means keeping the same data on multiple database servers (called replicas or nodes). When we write data to one server, that change gets copied to the others.

The goals are simple:

• High availability — if one server crashes, others take over
• Read scaling — spread read queries across multiple servers
• Low latency — place replicas closer to users in different regions

Single-Leader Replication (Master-Slave)

This is the most common setup. One node is the leader (master) and the rest are followers (replicas/slaves).

• All writes go to the leader
• The leader sends changes to all followers
• Reads can go to any follower (or the leader)

This is what PostgreSQL, MySQL, and MongoDB use by default. It’s simple and works well when reads far outnumber writes (which is true for most applications).

The downside? The leader is a single point of failure for writes. If it goes down, we need to promote a follower to become the new leader (failover).

Multi-Leader Replication

Instead of one leader, we have multiple leaders that all accept writes. Each leader replicates its changes to all others.

Use case: Multi-region deployments. We put a leader in each data center so users write to the nearest one.

The big problem is write conflicts. If two leaders update the same row at the same time, which one wins? We need conflict resolution strategies:

• Last write wins — the latest timestamp wins (simple but can lose data)
• Merge values — combine both changes (complex but preserves data)
• Let the application decide — store both versions and let the app resolve it

In simple language, multi-leader replication is like having two people editing the same Google Doc at the same time. It works, but we need a plan for when their edits conflict.

Leaderless Replication (Dynamo-Style)

No leader at all. Any node can accept reads and writes. The client sends writes to multiple nodes at once. This is the approach Amazon DynamoDB and Apache Cassandra use.

It uses a concept called quorum. If we have n replicas:

• Write to w nodes
• Read from r nodes
• As long as w + r > n, we’re guaranteed to read the latest value

For example, with 3 replicas: write to 2, read from 2. At least one of the nodes we read from will have the latest data.

Synchronous vs Asynchronous Replication

Synchronous: The leader waits until the follower confirms it saved the data before telling the client “write successful.” Guarantees the follower is up to date, but makes writes slower.

Asynchronous: The leader tells the client “done” immediately and replicates in the background. Faster writes, but the follower might be slightly behind.

Most systems use semi-synchronous — one follower is synchronous (so at least two nodes always have the latest data), and the rest are asynchronous.

Replication Lag

With asynchronous replication, followers might be seconds (or even minutes) behind the leader. This causes some weird problems:

Read-after-write inconsistency: A user writes a comment, then immediately reads the page — but the read goes to a follower that hasn’t received the write yet. The user’s own comment is missing.

Fix: Route reads for “own data” to the leader, or track the latest write timestamp and don’t read from a follower that’s too far behind.

Monotonic read inconsistency: A user reads from Follower 1 (which is up to date), then reads from Follower 2 (which is behind). It looks like data disappeared.

Fix: Ensure each user always reads from the same replica (sticky sessions).

Causality violations: User A writes “How’s the weather?” then User B replies “Sunny!” — but a follower receives B’s message before A’s, so the reply appears before the question.

In simple language, replication lag is the gap between what the leader knows and what the followers know. Most of the time it’s milliseconds, but under heavy load it can grow and cause confusing bugs.

When to Use What