Replication

SYSTEM DESIGN SERIES  ·  TOPIC 11 OF 23+  ·  part of the 10 → 11 → 12 chain
1. Synchronous vs Asynchronous - Watch the Client Wait
Same write, two very different experiences for the client (looping)
Sync: client's request doesn't return until the replica has confirmed too
Sync: client latency = leader write + full round trip to the replica
Sync: safer - the write is confirmed nowhere it isn't actually durable
Async: client gets confirmed right after the leader's own write
Async: replication to the replica happens after, in the background
Async: faster for the client - but that background copy can lag or vanish
2. Why Replicate At All?
One copy of the data is one copy too few
  • Durability - a lost node (topic 02) doesn't mean lost data
  • Read scaling - spread read traffic across replicas (topic 04)
  • Locality - a nearby replica answers faster than a distant leader (topic 08)
  • Availability - the system can keep serving reads even if the leader is down
🗄️ Replication is caching's cousin (topic 07) - except every "cache" here is a full, durable copy, not just a shortcut.
3. Leader-Based vs Leaderless
Leader-Based
  • One node accepts writes; others replicate from it
  • Simple, obvious source of truth
  • Leader is a bottleneck until it fails over
VS
Leaderless (Quorum)
  • Any node can accept a write
  • Reads/writes need a quorum: W + R > N
  • No single bottleneck, but conflicts get real
🏢 Analogy: Leader-based is one office that stamps every form, copies sent to branches. Leaderless is any branch can stamp a form, as long as enough branches agree on what's official.
4. Replication Lag & Reading Your Own Write
The gap between "the leader has it" and "the replica has it"
  • You write, then immediately read - routed to a replica that hasn't caught up
  • Your own write looks like it never happened, for a moment
  • Fixes: read-from-leader briefly after your own write, or sticky-read the same replica
5. Failover - When the Leader Dies
Someone has to notice, and someone has to be promoted
  • Detecting the leader is gone is topic 02's problem, all over again
  • The most caught-up replica should be promoted - not just any replica
  • Two nodes both thinking they're leader = split-brain - the real mechanics of choosing safely are topic 19 (Consensus)
6. Replication Topologies
Who copies from whom
Single-Leader (Star)
Multi-Leader
Chained / Cascading
Multi-Region
More topology usually means more conflict-resolution to design for
Star topology is the default for a reason. Reach for multi-leader or leaderless only when a single leader genuinely can't serve the traffic or geography.
7. Choosing Your Replication Strategy
Choose synchronous when:
✔ Losing a write is unacceptable (payments, ledgers)
✔ Your latency budget can absorb the round trip
✔ Replica count is small and nearby
Replication Trades Consistency for Availability - There's No Free Copy
Choose asynchronous when:
✔ Write latency matters more than replica freshness
✔ You're scaling reads across many replicas
✔ Some staleness is genuinely tolerable
💡 Once data lives in multiple places, at multiple times, what does "correct" even mean? That's Consistency Models - topic 12, next.