Three topologies
diagram
| Single-leader | Multi-leader | Leaderless | |
|---|---|---|---|
| Writes | One node | Several | Any quorum |
| Conflicts | None | Must resolve (LWW, CRDTs) | Must resolve (read repair) |
| Use | Default | Multi-region writes, offline clients | Very high write availability |
Sync vs async
- Synchronous: the write is acknowledged after replicas confirm. Durable, but slower, and blocks if a replica is down.
- Asynchronous: fast, but failover can lose acknowledged writes.
- Quorum / majority: MongoDB
w: "majority"means the write survives any single-node failure. The usual production choice.
Failure scenarios to design for
- Replication lag leads to stale reads from secondaries (see read-your-writes).
- Failover picks a new leader; clients must retry writes idempotently.
- Split brain: two nodes think they're leader. Prevent it with majority elections and fencing tokens.
- Leaderless quorums: with
W + R > N, reads overlap the latest write.
Cheatsheet
The whole topic on one page. Click to open full screen.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Distributed Systems & DataUnderstood
CAP & PACELC Theorems
During a network partition you choose consistency or availability; when there's no partition you still trade latency against consistency.
Intermediate5 sources
Distributed Systems & DataLearning
Consistency Models
From linearizable to eventual — what each guarantee means for users, and practical models like read-your-writes and monotonic reads.
Advanced4 sources
Distributed Systems & DataUnderstood
Sharding & Partitioning
Split data across nodes so storage and throughput scale horizontally — choosing shard keys, range vs hash, hot spots and rebalancing.
Advanced5 sources
Distributed Systems & DataApplied in production
MongoDB at Enterprise Scale
Data modelling by access pattern, indexing (ESR rule), transactions, change streams and the operational gotchas of large multi-tenant collections.
Advanced5 sources