Replication Patterns
Single-leader, multi-leader, or leaderless — each picks a different point on the consistency/availability/complexity spectrum.
What it is
Replication keeps copies of data on multiple nodes for availability, read scaling, and disaster recovery. Single-leader (Postgres streaming, MySQL primary-replica) routes all writes to one node which streams a log to followers; simple and consistent but the leader is a bottleneck and SPOF until failover. Multi-leader allows writes to multiple nodes which sync to each other; handles multi-region writes but introduces conflict resolution. Leaderless (Cassandra, Dynamo) lets any node accept writes with quorum-based consistency. Each replica can sync (block on commit until replicas ack) or async (fire and forget, replication lag).
Why senior interviewers ask
Replication is the foundation of every production database conversation. Senior interviewers want to hear you name the pattern, the sync mode, and the failover story explicitly.
Key points
- Single-leader: simple model, but writes bottleneck on one node; failover is the hard problem.
- Synchronous replication: leader waits for replica ack — durability up, latency up, availability down (replica down blocks writes).
- Asynchronous replication: leader doesn't wait — fast, but replicas lag and may lose recent writes on failover.
- Semi-sync (MySQL): leader waits for at least one replica ack — middle ground.
- Multi-leader: each region accepts writes, replicas sync between regions; conflicts need resolution (LWW, CRDTs (Conflict-free Replicated Data Types), app-side merge).
- Leaderless: writes go to any N replicas, reads check R replicas; R+W > N gives quorum consistency.
- Read replicas can serve stale reads — apps must handle replication lag (read-your-writes routing).
- Failover automation (Patroni, RDS) trades complexity for shorter RTO.
Pros
- Single-leader: simple semantics, easy reasoning, mature tooling.
- Multi-leader: multi-region writes, no cross-region latency for users.
- Leaderless: no single point of failure, tunable consistency per request.
- Read replicas: scale read throughput independently of writes.
Cons
- Single-leader: write throughput capped at one node; failover is complex.
- Multi-leader: conflict resolution is hard; CRDTs or LWW have surprising semantics.
- Leaderless: anti-entropy operations (read repair, hinted handoff) are operational tax.
- Async replicas: replication lag causes read-your-writes anomalies that break user experience.
When to choose
- Single-leader sync: financial systems where durability beats latency.
- Single-leader async: most web apps — fast writes, replicas catch up.
- Multi-leader: global apps where users must write to their local region.
- Leaderless: write-heavy, eventually consistent workloads (Cassandra, Dynamo).
When to avoid
- Multi-leader: when you can't tolerate or design for conflict resolution.
- Leaderless: when consistency matters more than availability and complexity tolerance is low.
Real systems
Interview probe
'Your primary fails. Walk me through what happens to writes in flight.' Answer: with async replication, recent writes acked to the client may not be on the replica — they're lost on failover. With sync, no loss but you needed the replica up. Name the RPO/RTO tradeoff explicitly.