Skip to content

Trade-offs · Production decisions

Leader-follower vs multi-leader vs leaderless replication

How to choose between leader-follower, multi-leader and leaderless replication, the numbers that change the answer, and what breaks with each.

Asked at: SDE-2Senior

The decision

Replication keeps copies of the same data on more than one server. The choice is who may accept a write. In leader-follower, one server (the leader) takes all writes, and the followers copy it. In multi-leader, several leaders take writes, usually one per region, and they copy each other. In leaderless, any copy takes a write, and the client sends it to several copies and waits for enough of them to confirm. More places to write gives better speed and uptime. But it brings write conflicts: two changes to the same item that neither side knew about.

Choose leader-follower when

  • Your writes fit on one server. Below, we assume that is 700 writes per second.
  • Most users are in one region, or the data has one natural home.
  • You need transactions and simple rules, with no conflict code.
  • You can accept a short pause on writes while a new leader is chosen.

Choose multi-leader when

  • Users are in two or more regions, and a write must finish near the user instead of crossing the world.
  • Each region must keep accepting writes when the link to the other region is cut.
  • Devices work offline and sync later.
  • Conflicts are rare, or you can merge them by rule.

Choose leaderless when

  • Writes must almost never be refused, and you can give up transactions across items.
  • Access is by key: get and put of a cart, a session or a profile.
  • You can pick the numbers R and W per operation and live with old reads when they are small.

The numbers that change the answer

Write limit (calculation). Assumption: one server takes 700 writes per second (the figure used in the replication lesson). Leader-follower stops there, because followers add reads, not writes. Leaderless on a ring of 9 nodes with 3 copies per item sends each write to 3 nodes. Each node then takes 3 / 9 = one third of all writes. The cluster takes 700 x 9 / 3 = 2,100 writes per second (this ignores the cost of coordination). Multi-leader does not raise the limit. Each leader must also apply the writes of the others, so all writes still have to fit in 700 per second on every leader.

Write time (assumption). Round trip Mumbai to Chennai: 30 ms. Disk write: 1 ms. A Chennai user writing to a Mumbai leader waits 30 + 1 = 31 ms. With a Chennai leader the wait is 1 ms.

Conflicts, worked example. Assumptions: 1,000,000 (10 lakh) items. Each item gets one write per day from Mumbai and one from Chennai, at random times.

  • Normal case: the copy delay is 1 second. A Mumbai write conflicts with a Chennai write that lands within 1 second before or after it. That chance is 2 / 86,400 per item per day (there are 86,400 seconds in a day).
  • Conflicts per day = 1,000,000 x 2 / 86,400 = 23.
  • Link cut for 1 hour: an item conflicts if both regions write it inside that hour. The chance is (1 / 24) x (1 / 24) = 1 / 576. Conflicts = 1,000,000 / 576 = 1,736.

A person can handle 23 conflicts a day. Nobody can handle 1,736 after one bad hour, so the merge rule must be automatic.

Failover time (assumption). A leader fails 4 times a year, and each failover takes 30 seconds with no writes. That is 30 x 4 = 120 seconds, or 2 minutes, a year. Leaderless has no failover step.

Quorum (cited idea). With 3 copies, W = 2 and R = 2, we have R + W = 4, which is more than 3. A read then meets the newest write. Cassandra documents this rule and lets you set the level for each operation (see Sources).

What breaks with each choice

Leader-follower.

  • The leader dies and the newest changes were not yet copied. With asynchronous copying they are lost. Fallback: wait for one follower on data you cannot lose.
  • The old leader comes back and thinks it is still the leader, so two servers take writes. Fallback: a fencing token, so the storage refuses the old leader.
  • Writes hit the 700 limit. Fallback: split the data over several leaders (sharding).

Multi-leader.

  • Conflicts. Last write wins keeps the write with the newest timestamp and silently drops the other. Many databases leave this to you. In Postgres logical replication, a conflict that causes an error stops the copying until a person fixes it (see Sources). Fallback: give each item a home region, or use merge rules.
  • Unique rules break: two regions can both create the username "asha". Fallback: check uniqueness at one home region.
  • Changes arrive out of order. Fallback: carry version numbers.

Leaderless.

  • With R + W not above N, a read can miss the newest write. Fallback: raise R or W for important operations.
  • Cassandra describes read repair and hinted handoff as best-effort, so copies can stay different. Fallback: run a full repair on a schedule.

What it costs

  • Servers. Multi-leader needs a full-size write server in every region. Leaderless stores each item 3 times.
  • People. Multi-leader and leaderless need a conflict rule for each kind of data. Assumption: one engineer-week per table or item type.
  • Changing your mind. Leader-follower to multi-leader is a hard change: every table needs a conflict rule, and every unique ID must work across leaders. Leaderless is usually a different database, so the move is a full migration with a copy-and-compare phase. Assumption: months. Start with leader-follower and add leaders only when a measured number forces it.

How each level answers

SDE-1: Leader-follower has one writer and many readers. Multi-leader has several writers. Leaderless has no special server.

SDE-2: I start with leader-follower, because it has no conflicts. I move to multi-leader only if users in another region cannot wait for a long trip to the leader.

Senior: One leader tops out near 700 writes per second here, and a Chennai write to Mumbai costs 31 ms against 1 ms. With multi-leader I expect about 23 conflicts a day, and about 1,736 after a one-hour link break. So most items get a home region and the rest get merge rules. The fallback is to send risky writes to one home region.

Staff: I ask what the business loses per second of write downtime and per second of delay in a far region. Two minutes of failover a year may cost less than the team time for conflict code. Also, a conflict bug can corrupt data without any alert. I start single-leader and make a second region a planned project with an ownership map: which team owns which item and its merge rule. I track conflicts per day, copy delay at the 99th percentile and lost writes after failover.

Say it in the interview

I would start with one leader and followers, because one server takes our 700 writes per second and there are no conflicts. If we add a second region, I would give each item a home region, so writes are local without conflicts for most data. For the rest I would use merge rules, and I expect tens of conflicts a day, which rises sharply when the link breaks.

Common mistakes

  • Choosing multi-leader for more write throughput in one region. It gives none. Split the data (sharding) instead.
  • Trusting "last write wins". It silently drops one write. For a balance or a cart, that loses money or items.
  • Thinking R + W above N is strong consistency. A read during a write can see either value. It is a quorum rule, not one copy.

Sources

Understand the trade-off. Practise explaining your choice.

In an AI mock interview, the interviewer can push on a choice like this one: it changes a number and asks if your answer still holds.

See the mock interviewsAll trade-offs