Primary-Replica vs Peer-to-Peer

Who is allowed to accept a write: one leader, one leader per region, or any node. How each choice handles failures, conflicts and distance, and how to pick one.

Overview

Copying data to several machines (replication) keeps it available when a machine dies and lets more machines serve reads. The hard question is not how to copy the data but who may accept a write. There are three answers, and each one shapes how the system behaves when things go wrong.

  • Single leader (primary-replica): one node takes every write and streams the changes to followers. PostgreSQL, MySQL and MongoDB replica sets work this way.
  • Multi-leader: several nodes take writes, usually one per region, and send their changes to each other. CouchDB and DynamoDB global tables work this way.
  • Leaderless (often called peer-to-peer): any replica takes a write, and the client or a coordinator talks to several replicas at once. Cassandra and Riak follow Amazon's 2007 Dynamo design.

With one writer there are no write conflicts, but that writer is a bottleneck and a failover risk. With many writers, writes are local and never wait for a failover, but two writers can change the same data at the same time, and something must decide which change survives.

What you will be able to do

  • Explain the three topologies and name a real system that uses each one.
  • Say what asynchronous replication risks during a failover, and how to prevent split brain.
  • Work through the quorum rule R + W > N, and list the cases where it still returns old data.
  • Choose a conflict resolution method (last write wins, a merge, a CRDT) and say what it loses.
  • Pick a topology for a given workload, including a multi-region one.

Key concepts

  • Single-leader replication
  • Synchronous and asynchronous replicas
  • Failover and split brain
  • Multi-leader replication
  • Leaderless replication
  • Quorums (R + W > N)
  • Conflict resolution
  • Consensus per shard

Interview questions

  • Compare single-leader, multi-leader and leaderless replication. When would you use each?
  • How do quorum reads and writes work, and when do they still return old data?
  • How do you handle write conflicts in multi-leader and leaderless systems?
  • How do you prevent split brain in a primary-replica system?
  • Is DynamoDB leaderless? What about Cassandra and CockroachDB?
  • Design the database layout for an app with users in the US, Europe and Asia.
  • Why do followers make failover lose data, and how do you limit it?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio