Replication

The Definition

 REPLICATION: maintain complete copies of the same dataset
 on multiple nodes.

              ┌─► replica-1 (full copy)
 primary ─────┼─► replica-2 (full copy)
 (writes)     └─► replica-3 (full copy)

 distinct from PARTITIONING/SHARDING: nodes hold DIFFERENT
 subsets of data. replication duplicates; sharding divides.
 large systems do BOTH: each shard replicated N ways.

What Replication Buys

Benefit	Mechanism
Availability	Primary dies → promote a replica
Read scaling	Spread reads across replicas
Locality	Replica near users/region reduces latency
Backup safety	Live copy ≠ backup, but helps recovery
Maintenance	Upgrade replicas one at a time, then switchover

Replication Modes

 SYNCHRONOUS: primary waits for replica ack before commit
   + zero data loss on failover
   − write latency = slowest replica; replica down blocks writes
 
 ASYNCHRONOUS: primary commits locally, ships changes later
   + fast writes, tolerant of replica lag/outage
   − failover can lose recent writes (replication gap)
 
 SEMI-SYNC: wait for ONE ack (not all)
   middle ground — common production choice

The sync choice is a durability-vs-latency decision made per system, not per industry.

Replication Lag: The Tax

Async copies fall behind:

 user updates profile → write hits primary
 immediate read → load-balanced to lagging replica → OLD DATA

 classic bugs this causes:
 - "I changed my email but it shows the old one"
 - order placed, order history missing it
 - password changed, old session still valid on replica reads
 
 lag is normally milliseconds; under load/failover it SPIKES —
 design for the spike, not the average

Read Routing Discipline

 which traffic can tolerate stale reads?
 ✓ feeds, profiles, catalogs, analytics    → replicas happily
 ⚠ recommendations                          → usually fine
 ✗ billing, auth checks, balance checks     → primary
 
 pattern: route by consistency need, not round-robin luck.
 "read-after-write" consistency (next lessons) handles
 the user-sees-their-own-writes case explicitly

Failover Mechanics

 primary death:
 1. detect      health checks / consensus loss of leader
 2. elect       pick most-caught-up replica
 3. promote     replica becomes writable
 4. reroute     clients/DNS/proxy to new primary
 5. reconcile   old primary returns → demote or split-brain guard

 dangers: split brain (two primaries!), lost writes from
 async gap. managed databases automate this; understanding
 what they automate is still your job in interviews

Interview Framing

“Scale the database for reads” = replication answer with structure: sync mode chosen deliberately, read routing by consistency tolerance, lag failure modes named (read-your-writes), failover sketch with split-brain mention. Then the honest limit: replication doesn’t help WRITE scaling — that’s sharding’s job, the natural follow-up.