A replication strategy where multiple databases can accept writes, and changes are shared among them.
Having just one leader can become a bottleneck or increase latency. Multi-leader replication allows multiple databases to process writes, improving availability and write performance in geographically distributed systems.
Use this when you want faster local writes in multiple regions or need high availability even when one leader goes down.
You need to know
Write conflicts can happen: Since multiple leaders can write at the same time, you must detect and resolve conflicting updates (via timestamps, version vectors, or app logic).
Data changes must be replicated between all leaders: Every write on one node must be synced to the others, usually asynchronously, to avoid blocking.
More complex failure handling: You get better uptime, but more complexity in conflict resolution, replication loops, and eventual consistency.
Topology matters: You can connect leaders in a ring, mesh, or star pattern. The more connected they are, the faster data propagates, but also the more complex it gets to manage and avoid replication loops.
Popular technologies
PostgreSQL – Since version 9.0 supports multi-leader replication through pglogical.
Amazon Aurora: Amazon Aurora also supports multi-leader replication with a modified ring topology.
MongoDB: MongoDB uses replica sets, where one node can be the primary (leader) for write operations, but multiple replicas can be configured to accept writes in multi-leader scenarios..
Like posts like this?
Every week, you'll get a new system design concept, broken down like this one.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️