Distributed Systems for Backend Engineers · Distributed Systems Fundamentals
Replication Strategies
Single-leader, multi-leader and leaderless replication.
Single-leader: one primary accepts writes, followers replicate (sync or async); simple and consistent, failover is the hard part. Multi-leader: several nodes accept writes (multi-region, offline clients) — requires conflict resolution. Leaderless (Dynamo-style: Cassandra, Riak, DynamoDB internals): clients write to several replicas with quorums, repairs reconcile divergence. Replication can be synchronous (durability, latency) or asynchronous (fast, possible data loss on failover).
Replication strategies
| Criterion | Single-leader | Multi-leader | Leaderless |
|---|---|---|---|
| Write availability | Leader only | Any leader | Any replica (quorum) |
| Conflicts | None (single order) | Must resolve | Must resolve (versions/LWW) |
| Failover | Leader election needed | Other leaders continue | No failover concept |
| Consistency | Strong on leader | Eventual across leaders | Tunable (R + W > N) |
| Examples | PostgreSQL, MySQL | Multi-region DBs, CouchDB, offline apps | Cassandra, ScyllaDB |
Common pitfalls
- Async replication assumed lossless on failover.
- Multi-leader without a conflict strategy.
- Split brain: two leaders after a partition without fencing.
Key points
- Single-leader is simplest
- Multi-leader/leaderless need conflict handling
- Sync vs async = durability vs latency
Further reading: Designing Data-Intensive Applications, ch. 5
Practice questions
What data can be lost when failing over an asynchronously replicated database?
Answer
Writes acknowledged by the old leader but not yet replicated to the new leader.
What is split brain?
Answer
A partition causes two nodes to both believe they're the leader and accept conflicting writes; prevented with quorum-based election and fencing.
Open in the app to mark lessons complete, take notes and track your progress.