# Leader-follower vs Multi-leader replication > Leader-follower replication, often called master-slave, accepts writes through one leader per replication group; multi-leader replication, often called master-master, lets multiple leaders accept writes to the same data. Choose leader-follower for simpler write ordering and invariant enforcement, and multi-leader when local writes or disconnected operation justify explicit conflict handling. Source: https://sysround.com/compare/leader-follower-vs-multi-leader Updated: 2026-11-05 ## Side by side | | Leader-follower | Multi-leader replication | |---|---|---| | Write routing | One writable leader per replication group | Multiple writable leaders for the same data | | Read scaling | Followers can serve reads, possibly stale | Local replicas can serve reads, possibly stale | | Cross-region writes | Remote clients usually contact the leader region | Local acknowledgment is possible with async replication | | Concurrent updates | One leader orders writes; transactions enforce invariants | Concurrent writes across leaders need coordination or merging | | Replication acknowledgment | Async or synchronous, depending on durability needs | Often async across regions; coordination adds latency | | Network partition | Safe writes require one authorized leader and required replicas | Isolated leaders can accept writes if divergence is allowed | | Failure recovery | Promote a follower and fence the old leader | Reroute traffic, then reconcile divergent histories | | Operational burden | Replication lag, elections, and safe failover | Those concerns plus conflict handling and convergence | ## The differences that matter The key distinction is who can write the same data, not how many writable servers exist. A sharded database can have hundreds of leaders while remaining leader-follower within each shard. Routing each customer to one home region avoids many conflicts, but it is not unrestricted multi-leader writing for that customer's data. Leader-follower gives each replication group a single write-ordering point. That makes conditional updates, uniqueness checks, and transactions easier to reason about, but does not automatically provide linearizable reads or serializable transactions. Reads from asynchronous followers can be stale, and failover can lose acknowledged writes if those writes never reached the promoted replica. Asynchronous multi-leader replication lets regions acknowledge local writes without waiting for a distant region. The cost appears when two regions change the same record before exchanging updates. Last-write-wins can discard a valid update, clock skew can distort timestamp ordering, and merging individual fields may still violate a business invariant. Failure handling changes rather than disappears. Leader-follower needs a safe promotion process and fencing so an old leader cannot keep accepting writes. Multi-leader can keep isolated regions writable, but only if the application tolerates divergence; enforcing global uniqueness, scarce inventory, or account-wide limits still requires coordination or explicit allocation of ownership. ## Choose Leader-follower when - Correctness depends on one authoritative decision for a seat, balance, lease, or inventory item, backed by appropriate transactions or conditional writes. - Most writes originate in one region, or remote write latency is acceptable. - The workload is read-heavy, so follower reads and caching provide enough scale without adding more writers. - Conflicting updates have no safe automatic merge, and rejecting or delaying writes is preferable to accepting incompatible outcomes. ## Choose Multi-leader replication when - Users in several regions need local write acknowledgment, and temporary cross-region inconsistency is acceptable. - Regions must continue accepting writes during link failures, with a defined reconciliation policy after recovery. - Updates have explicit merge semantics, such as set operations or suitably designed CRDT operations. - Overlapping edits are acceptable as visible conflicts, such as file versions that users can review instead of silently overwriting. ## Worked example: Two regions competing for one seat Assume a booking service runs in two regions with a modeled 100 ms round-trip time between them. One seat remains, and both regions receive a purchase request within 20 ms. With asynchronous multi-leader replication, each region can observe the seat as available and acknowledge a sale before learning about the other. Last-write-wins cannot undo the promise made to the losing customer. With leader-follower replication, both requests go to the seat's authoritative leader, where an atomic conditional update allows only one sale. The remote buyer pays the cross-region latency cost. If regional independence is required, allocate disjoint inventory to regions rather than letting both sell the same seat. ## In the interview - Start with the invariant: explain whether two regions may both acknowledge updates to the same item. Expect the interviewer to test this with a concurrent reservation or conflicting edit. - State the acknowledgment rule separately from the topology. Explain whether success means local durability, receipt by a synchronous replica, or commitment by a quorum, and what failures that survives. - Walk through a network partition and recovery. For leader-follower, cover leader authority, promotion, and fencing; for multi-leader, show two conflicting writes and their exact resolution. - Separate read guarantees from write routing. Explain how read-your-writes works after a regional switch, and whether stale follower reads are acceptable. - Discuss write scaling honestly: adding leaders does not automatically multiply capacity because each replica may still apply every write. Use sharding when the goal is distributing independent data. ## Common mistakes - Claiming leader-follower automatically provides strong consistency, without specifying read routing, transaction isolation, acknowledgment rules, and failover behavior. - Treating last-write-wins as a lossless merge or assuming wall-clock timestamps establish a trustworthy global order. - Choosing multi-leader to prevent downtime while ignoring global constraints, conflicting writes, and reconciliation. - Confusing multiple shard leaders with multiple leaders accepting writes to the same records. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Replica write authority determines partition behavior, durability guarantees, and how conflicting values converge. - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Concurrent sales across regions expose why asynchronous multi-leader replication cannot alone protect scarce inventory. - [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Offline and regional updates require explicit versioning and conflict handling rather than silent overwrite. - [Design Google Docs](https://sysround.com/questions/design-google-docs): Accepting concurrent edits requires distinguishing database replication from application-level edit merging. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Safe promotion, fencing, and recovery are central to managing replicated database instances. ## FAQ ### What is the difference between master-slave and master-master replication? Master-slave usually means leader-follower: one leader accepts writes and replicates them to followers. Master-master usually means multi-leader: more than one leader accepts writes to the same data. The second topology needs coordination or conflict resolution when those writes overlap. ### Is multi-leader replication strongly consistent? Not by itself. Asynchronous multi-leader replication allows replicas to diverge and requires a convergence policy. Strong guarantees for shared data require coordination, which can add cross-region latency and prevent some regions from accepting writes during a partition. ### Does multi-leader replication improve write performance? It can reduce client-visible write latency when clients write to a nearby leader without waiting for remote replication. It does not necessarily increase total write throughput because replicas may still process all writes, plus conflict-resolution work. Sharding is the more direct way to distribute independent write workloads. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Multi-region architecture](https://sysround.com/concepts/multi-region-architecture) - [Conflict resolution and last-write-wins](https://sysround.com/concepts/conflict-resolution) - [Split brain](https://sysround.com/concepts/split-brain) - [Leader election](https://sysround.com/concepts/leader-election) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.