Leader-follower vs multi-leader replication

WHAT THIS TESTS Whether you grasp where writes go in a replicated system and how that choice trades simplicity for write scalability and availability.

A GOOD ANSWER COVERS In leader-follower, one node is the primary and accepts all writes, streaming changes to followers that serve reads. This is easy to reason about: there is a single ordering of writes, so no conflicts arise. The downsides are that the leader is a write bottleneck and a failure point, and clients far from the leader pay latency. Multi-leader replication runs several nodes that each accept writes, typically one per region or datacenter, replicating asynchronously to the others. It solves write latency for geographically spread users, tolerates a regional outage continuing to accept writes, and supports offline-capable clients.

COMMON WRONG ANSWERS Saying multi-leader simply scales writes infinitely, or forgetting that asynchronous replication means two leaders can accept conflicting edits to the same row before they sync.

LIKELY FOLLOW-UPS How do you resolve conflicts? Options include last-write-wins by timestamp, which can silently drop data; application-defined merge logic; version vectors to detect concurrency; or conflict-free replicated data types. How do you avoid write loops in the replication topology?

ONE CONCRETE EXAMPLE A collaborative calendar with users in Tokyo and London uses multi-leader replication so each region writes locally with low latency. When both regions edit the same event title before syncing, the system detects the concurrent versions and either picks the highest timestamp or surfaces both for the user to merge, rather than silently losing one edit.