Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · senior level

Leader–follower, multi-leader, leaderless — what does each buy you, and what does each cost?

🎤 Say this first

Single-leader (Postgres, MySQL, MongoDB, Kafka partitions): all writes go to one node, so write conflicts are impossible by construction — the leader defines the order. You pay with a write bottleneck and a failover gap. Multi-leader (multi-region active-active, CouchDB): each region accepts local writes for low latency and survives regional isolation — but two regions can now write the same row concurrently, so you have signed up for conflict resolution, permanently. Leaderless (Dynamo, Cassandra, Riak): clients write to N replicas and read from several, using quorums for consistency and read-repair/anti-entropy for convergence — excellent availability and elastic scaling, with the same conflict problem plus tunable staleness. The decisive question is not throughput, it's who is allowed to order two concurrent writes.

The full picture

Single-leaderMulti-leaderLeaderless
Write conflictsimpossibleguaranteed eventuallypossible, resolved at read/repair
Write latencyone region's RTTlocal — the main drawfastest W of N replicas
Failoverelection + gapnone needednone needed
Ops complexitylowhigh (conflict rules, loops)medium (tuning N/R/W, repair)
Good forOLTP, ordered logsgeo-local writes, offline clientshigh-availability KV at scale
  • Single-leader is the right default and you should say so: most systems that 'need' multi-leader actually need a read replica per region plus a single global write leader. Adding leaders adds a conflict-resolution problem that never goes away, and teams consistently underestimate it.
  • Multi-leader's hidden costs beyond conflicts: replication topology loops (star vs all-to-all vs circular — all-to-all reorders messages, circular breaks when one node dies), auto-increment IDs colliding, and triggers/constraints that were only ever checked on one node. Uniqueness constraints are the killer — they're a global invariant and multi-leader has no global anything.
  • Leaderless is not 'no coordination': coordination moved to the client/coordinator and to quorum arithmetic. Cassandra's LWT (IF NOT EXISTS) exists precisely because some operations need Paxos even in a leaderless store — and it's an order of magnitude slower, which is the honest trade to mention.
  • Offline-first clients are secretly multi-leader: a mobile app with a local database that syncs is exactly an extra leader, complete with concurrent edits and merge semantics. Framing it that way (CouchDB/PouchDB, Realm, local-first apps) shows the pattern generalizes beyond datacenters.
  • Kafka is the useful hybrid to name: per-partition single leader (so ordering is total within a partition and conflicts impossible), many partitions for scale, ISR-based replication for durability. It's the clearest example of 'shard so each shard has one writer', which is the pattern most designs should copy.

🔄 Likely follow-up questions

  • Why are uniqueness constraints so hard in a multi-leader setup?
  • How does Kafka avoid write conflicts without giving up horizontal scale?
  • When is a read replica per region strictly better than a second leader?