With one leader, every write in the world goes to one machine. That's what makes single-leader replication simple: there's one place where things happen, in one order. It's also its biggest limit. If that machine is far away, every write is slow. If it's unreachable, nobody can write at all.
Multi-leader replication lets more than one replica accept writes. Each leader takes writes locally and sends them to the others in the background. You get writes that are fast and keep working when the leaders can't talk to each other. You pay for it with a problem single-leader never has: two leaders can accept conflicting writes to the same data at the same time.
Why you'd want more than one leader
Three situations push systems this way.
| Situation | Why one leader hurts | What multi-leader gives |
|---|---|---|
| Users in several regions | A London restaurant's every write crosses to Mumbai and back, ~120 ms | Each region writes to its own leader in ~1 ms |
| Devices that go offline | A kitchen tablet with no Wi-Fi can't write anything | The device's local copy is a leader; it syncs later |
| Collaborative editing | Each keystroke waiting on a server feels laggy | Each user's copy accepts edits instantly |
The last two are easy to miss. Any app that lets you make changes while offline and syncs them later is running multi-leader replication, with every device as a leader. Calendar apps, note apps and Google Docs-style editors all live here.