Database Replication: Copies for Scale and Survival

A cache shields your database from reads, but the database still has to own the data — and a single database is both a capacity limit and a single point of failure. Replication addresses both by keeping live, synchronized copies of your data on multiple servers. It's usually the first step in scaling a database, and it buys you two things at once: more read capacity and survival when a server dies.

The idea: keep synchronized copies

Replication maintains multiple copies of your database that stay in sync. The standard arrangement has two roles:

Role	Handles	How many
Primary	All writes	One
Replica	Reads	Several

The primary accepts all writes and streams its changes to the replicas, which apply them to stay current. Replicas then serve read queries.

Writes

↓→

Primary

↓→

Stream changes

↓→

Replicas serve reads

Scaling reads

The first payoff is read scaling, and it works because of a happy fact about most applications: they read far more than they write. Browsing, searching, viewing — vastly more common than posting or editing.

Reads

95%

Writes

5%

Replication lets you spread that dominant read traffic across many replicas, while the primary only has to handle the small slice of writes. Need more read capacity? Add another replica. For read-heavy systems — which is most of them — this alone removes the database as a bottleneck for a long time.

Note what it doesn't solve: writes still all go to the single primary. Replication scales reads, not writes. Scaling writes is a harder problem we'll meet in the next chapter.

High availability and failover

The second payoff is survival. A replica is a continuously-updated, warm copy of your data — which means if the primary fails, you're not stuck. One of the replicas can be promoted to become the new primary, a process called failover.

Failover can be automatic or manual, but the principle holds: because the data already lives in more than one place, no single database server is irreplaceable.

The catch: replication lag

Now the part that trips everyone up. Streaming changes from primary to replicas takes time — usually milliseconds, sometimes more under load. During that window, a replica is behind the primary. This delay is called replication lag, and it has a real consequence:

This is the signature bug of read replicas, and it's not a malfunction — it's the fundamental nature of asynchronously-updated copies.

Eventual consistency

Replication lag means your replicas are eventually consistent: given a pause in writes, every copy will converge to the same state — but at any instant, a replica may be slightly stale. This is a genuine trade-off, not a flaw:

• Strong consistency (always read the latest) would mean reading from the primary, giving up the read-scaling benefit.
• Eventual consistency (reads may be a touch old) is what lets replicas absorb read load.

The real engineering is designing around the lag: routing reads that must be current to the primary (like immediately after a user's own write), while sending the vast majority of reads — where a few milliseconds of staleness is harmless — to replicas. Knowing which reads tolerate staleness, and which don't, is the skill replication demands.

Recap

• Replication keeps synchronized copies of your database across servers, for scaling and resilience.
• A primary takes all writes and streams changes to replicas, which serve reads.
• It scales reads brilliantly (most workloads are read-heavy) but does not scale writes — those still hit one primary.
• Replicas enable high availability: if the primary fails, one is promoted (failover).
• Replication lag makes replicas eventually consistent — design around it by routing must-be-fresh reads to the primary.

Replication scales reads but leaves all writes on one primary. When writes themselves outgrow a single server, you split the data — that's sharding. Continue to Database Sharding.