Back to roadmap
Module 3 · Consistency & ReplicationDay 02425 min

Replication Topologies

Single-leader, multi-leader, leaderless — pick a coordinator strategy.

← PreviousNext →
Day 024

Replication Topologies

Single-leader
service
Multi-leader
service
Leaderless
service
Signal path
Three topologies
Single-leader
service
async
PG, MySQL, Mongo
note
Multi-leader
service
async
Active-active geo
note
Leaderless
service
async
Cassandra, Dynamo
note
Memory hook

Replication Topologies: single-leader, multi-leader, leaderless

Mental model

choose the failure mode you can explain

Design lens

Multi-leader/leaderless raise complexity; single-leader keeps it boring.

Recall anchors
Single-leaderMulti-leaderLeaderless

Why it matters

Single-leader writes through one node and replicates out (Postgres, MySQL, MongoDB). Multi-leader writes to several leaders and reconciles. Leaderless lets any replica accept writes (Dynamo, Cassandra). Conflict potential rises as you remove the leader.

Deep dive

Single-leader is simplest and most common; failover is the hard part.

Multi-leader handles geo-distributed writes; conflict resolution is the hard part.

Leaderless uses quorums and last-writer-wins or CRDTs; tunable consistency.

Demo / scenario

Geo-distributed editing app needs to accept writes in 3 regions.

  1. Single-leader: cross-region writes are slow, unhappy users.
  2. Multi-leader: each region writes locally; CRDTs resolve conflicts.
  3. Leaderless: each region quorums internally; cross-region replication is async.

Tradeoffs

  • Multi-leader/leaderless raise complexity; single-leader keeps it boring.
  • Conflict resolution rules vary in correctness for the workload.
  • Choosing topology is a workload choice, not a status symbol.

Diagram

Single-leader
Multi-leader
Leaderless
PG, MySQL, Mongo
Active-active geo
Cassandra, Dynamo
Three topologies.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →