Replication

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 1 — The building blocks

Layer 1 · Post 14 of 15

← Previous: Database Indexes → Next: Sharding

Layer 1 — The building blocks · Post 14 of 88

Replication copies data to more machines so reads can scale and a failure does not take the data with it.

What you'll learn

Leader/follower (primary/replica) replication in one picture
Why replicas can be slightly behind, and when that matters
What replication does not solve (writes still have a bottleneck)

The idea in one minute

Replication means the same data lives on more than one machine.

Usual setup:

One primary (leader) takes writes.
One or more replicas (followers) copy those writes and serve reads.

        writes
          |
          v
      [ Primary ] ----stream of changes----> [ Replica ]
          ^                                      |
          |                                      v
        (failover if primary dies)            reads

If the primary's disk dies, a replica can be promoted. If read traffic is heavy, replicas share the load. That is the deal.

You will meet replication again in Layer 3 as a reliability topic (failover, lag, split-brain). Here it is the building block: copy the data.

Why it matters

A single database node is a single point of failure and a single read bottleneck.

Replication is the first honest answer to:

"What if that VM disappears?"
"Reads are 10× writes; can we scale reads?"

It is not the first honest answer to "writes no longer fit on one machine." That is sharding (next post). Replicas still apply the same write stream. You did not split the write volume; you copied it.

How it works

How the copy travels

Most relational systems ship a log of changes (WAL, binlog) from primary to replica. The replica replays it. The replica is not a second independent brain; it is a delayed mirror.

Synchronous replication: primary waits until a replica has the write. Safer. Slower. If the replica is in another region, every write pays that RTT.

Asynchronous replication: primary says success when it has the write. Replicas catch up. Faster. On failover you might lose the last few writes that never made it across. Many production Postgres/MySQL replicas are async by default.

Read your own write

You update your display name and immediately reload. The load balancer sends the GET to a replica that is 200 ms behind. You see the old name. You think the save failed.

Fixes: read the primary after writes, use "session" or "causal" stickiness, wait for the replica to catch up, or accept the glitch for that product.

Replication vs backup

A replica is hot and close to live. A backup is a point-in-time copy, often in object storage, for "we deleted the wrong table yesterday." You want both. A replica that was already corrupt or empty will happily replicate emptiness.

A simple example

An online store:

Checkout writes (create order) go to the primary.
Product browsing reads go to replicas (and Redis, and the CDN).
Overnight analytics might use a separate replica so a heavy report does not lock the primary.

Primary in us-east-1, replica in us-west-2: regional outage is survivable if you can promote the west replica and point the app at it. DNS and connection strings have to change (or a proxy does). Lag and "did the last orders replicate?" become the incident.

Common mistakes

Sending writes to replicas. Unless you designed multi-primary (hard), replicas are read-only. Accidental writes go to the primary only — by policy, not by hope.

Assuming replicas are identical right now. They are identical eventually, on async replication.

One replica, same rack, same disk type, thinking you have DR. You have a slightly nicer single datacenter.

Counting replica RAM as "more write capacity." Write capacity is still roughly the primary's.

How this shows up in real systems

RDS / Cloud SQL read replicas: the managed version of this diagram.
Redis replica, Kafka follower, etcd voters: the idea repeats in every stateful system. Consensus (Layer 3) is replication with stricter voting rules.
Multi-region databases (Spanner, Cosmos, DynamoDB global tables): replication as a product, with explicit consistency choices.

Layer 3 will return to failover and leader election. This post is enough to draw a primary and two replicas and know what each is for.

Recap

Replication copies data for read scale and survival.
Async is fast and can lose tail writes on failover; sync is safer and slower.
Replicas do not split write load. For that, you shard.