Sign in
TodayMapLearnPracticeReview
All labs
Lab 04 · Replication

Copy data so one failure doesn't take you down

Writes go to the primary. Reads can come from anywhere. Lag is the tax you pay.

What problem are we solving?
A single database is a single point of failure: if it dies, every read and write dies with it. Replication copies writes from a primary to N replicas in real time. Reads can now hit any copy — which means you scale read capacity and survive a primary crash. The tradeoff: replicas are eventually consistent. Between a write landing on the primary and that write reaching a replica, there is a window where the replica will serve old data. The size of that window is the replication lag.
Live simulation
updates every 1s
Primary
0 writes/s25% reads
replicate
lag 200ms
R125% reads
R225% reads
R325% reads
Writes
✓ ok
Stale risk
4%
Availability
100%

Stale-read chance scales with replication lag. 100 ops per tick; reads split across primary + replicas.

Controls
3
80% reads
200ms
Failure scenario

Primary is healthy. Reads are split across primary + replicas.

Live metrics
Reads this tick025% primary · 75% replicas
Writes this tick0
Stale reads04% of replica reads
Failed writes0
Read availability100%
Write availability100%
Stale-read risk

At 200ms lag, ~4% of replica reads serve data older than 1000ms. Effectively fresh for most workloads.

What just happened?
0 reads/s and 0 writes/s flowing. Writes hit the primary; reads are spread across the primary and 3 replica(s) at 25/75% split. Lag is low (200ms) — stale reads are negligible.
Try this

Survive a primary failure

Hit "Fail primary" — every write starts failing. Then click "Promote replica" to failover. The gap between those two clicks is your downtime.

If your reads can tolerate a 5s staleness but writes cannot, where do you send reads vs writes? What is the smallest replication lag you can afford?

Key takeaway
Replication buys you read scale and availability at the cost of consistency. The lag number is not a metric — it is a contract: every read from a replica is a bet that the lag is small enough for your workload. Reads-after-writes must go to the primary. Everything else can fan out.
Related concepts
  • Replication
  • Failover
  • Leader Election
  • Consistency Patterns