Why more than one leader
A single leader is a bottleneck and a single point of failure for writes. Multi leader replication lets several nodes accept writes, often one leader per datacenter. Each leader replicates its changes to the others.
Where it helps
- Multi datacenter each region writes locally with low latency and replicates across regions in the background.
- Offline clients a phone app acts as its own leader and syncs when reconnected.
- Collaborative editing many users write concurrently to shared state.
The core problem is conflicts
Because two leaders can accept writes to the same record at the same time, you get write conflicts that a single leader would have serialized. The system must detect and resolve them.
Resolving conflicts
- Last write wins keep the highest timestamp but silently drop data.
- Merge combine both values when the type allows it.
- Application logic prompt the user or apply a domain rule.
Avoid conflicts entirely by routing all writes for a given record to the same leader when possible.
Key idea
Multi leader replication boosts write availability and locality but forces you to detect and resolve the write conflicts that concurrent leaders create.