What it is
Replication keeps copies of the same data on multiple nodes, for durability (survive a node loss), availability (serve from a surviving copy), and read scale (spread reads across copies). Useful replication requires picking two things: a topology (who accepts writes) and a timing (synchronous or asynchronous propagation).
When you care
Replication is the follow-up to almost every storage answer: “You said replica — what happens when the primary dies?” The trap is saying “leader-follower replication” without naming the failover story or the lag anomalies. Interviewers probe what happens to acknowledged writes during failover, what stale reads the followers serve, and — for multi-writer designs — how conflicting writes resolve.
The topologies
| Topology | Who accepts writes | Conflicts | Failure behavior | Used by |
|---|---|---|---|---|
| Leader-follower | One leader per dataset/partition | None — single writer orders all | Failover window: writes block (or lose data) until a follower promotes | Postgres/MySQL replicas, Redis, MongoDB |
| Multi-leader | One leader per region/site | Yes — same key writable in two regions | Regions survive independently; conflicts surface on sync | Cross-region SQL, CouchDB, calendar/offline apps |
| Leaderless (quorum) | Any replica (coordinator fans out) | Yes — concurrent writes create siblings | No failover step; quorum assembles from whoever is alive | Dynamo, Cassandra, Riak |
Leader-follower is the default for a reason: a single writer means a single ordering, no conflicts, and simple reasoning. The two costs: reads from followers are stale by the replication lag, and failover is a real event — detect the dead leader, elect a replacement, repoint clients. Done badly (promote a lagging follower), failover loses acknowledged writes; done conservatively, writes block for the duration.
Multi-leader exists for geography: each region writes locally at local latency, and regions exchange changes asynchronously. The price is genuine write conflicts — the same row updated in two regions — which need a resolution policy (last-write-wins, per-field merge, or app-level handlers). Reach for it when regional write latency is a requirement, not before; conflict handling is a permanent tax on every schema decision afterward.
Leaderless removes the failover event entirely: a write succeeds when any
W of N replicas acknowledge, a read consults R, and R + W > N makes the
sets overlap. Failure handling becomes arithmetic instead of choreography.
The price is the same as multi-leader’s — concurrent writes conflict — plus
version metadata (vector clocks or LWW timestamps) on every record.
Sync vs async propagation
| Timing | Acknowledged write means | Cost |
|---|---|---|
| Synchronous | Data is on N replicas before the client sees OK | Write latency includes the slowest replica; a dead replica blocks writes |
| Asynchronous | Data is on 1 node; replicas catch up later | Window where leader death loses acknowledged writes |
| Semi-sync / quorum | Data is on W-of-N replicas | The practical middle: tolerate N−W slow/dead replicas, bound the loss window to zero |
Fully synchronous to all replicas is rare (one dead follower halts writes); fully asynchronous is common and quietly dangerous (failover = data loss). Most production answers are quorum-shaped: “acknowledged when 2 of 3 have it.”
Replication lag anomalies
Async replication makes followers time-travel slightly. Three named anomalies interviewers expect you to know:
- Read-your-writes violation — you post a comment, refresh, it’s gone (the read hit a lagging follower). Fix: route a user’s reads to the leader briefly after their writes, or pin by session.
- Monotonic reads violation — refresh twice, data goes backward (second read hit a more-lagged follower). Fix: pin each user to one replica (hash by user ID).
- Causality violation — an answer is visible before its question (different partitions, different lag). Fix: causal ordering metadata, or accept it — most products do.
When to pick what
- Default, single region: leader-follower with quorum-style ack (semi-sync), automated failover, and lag monitoring.
- Multi-region writes required: multi-leader with an explicit conflict policy — or push back on the requirement.
- Always-writable contract, conflict-tolerant data: leaderless quorum (R+W>N), vector clocks or CRDTs.
- Read scale only: leader-follower with read replicas — and name the lag anomalies you’re accepting.
Related
- Walkthrough: Designing a Distributed Key-Value Store — leaderless replication built out in full: sloppy quorums, hinted handoff, anti-entropy repair.
- Reference: Consistency Models — the guarantees vocabulary (linearizable, causal, eventual) that replication choices buy or break.
- Reference: Distributed Transaction Patterns — what it takes to write two things atomically, which replication alone never gives you.