Skip to content

Leader-Based Replication

Replication protocol — instantiates Shared-State Consistency Contract Design

Routes every write through a single designated leader that orders it and streams it to followers, giving one authoritative sequence of updates for a piece of state.

Leader-Based Replication (single-leader / primary-replica) designates one replica as the authority for a piece of state: all writes go to the leader, which puts them in a definite order and streams that ordered log to its followers, who apply it in the same sequence. Its distinguishing property is a single point of ordering — because exactly one node accepts and sequences writes, there is never a write-write conflict to resolve, and the leader's log is the authoritative history. It buys simple, conflict-free ordering at the price of funneling all writes through one node and needing a failover story for when that node dies.

Example

A URL-shortener service runs its core database as one primary plus three asynchronous read replicas. Every new short link is written to the primary, which assigns each a position in its write-ahead log and ships the log to the replicas; the replicas serve the high-volume redirect reads and lag the primary by tens to hundreds of milliseconds. This gives the service a clean contract: writes are totally ordered (whatever the primary decided), a redirect served from the primary is fully up to date, and one served from a replica is consistent but possibly a few milliseconds behind — so a link created a moment ago may briefly 404 on one replica. When the primary fails, one replica is promoted — and the design's hardest question is not normal operation but exactly that failover: how to promote without losing the tail of un-replicated writes or briefly admitting two leaders.

How it works

The distinctive thing is that authority is positional — held by one node at a time. The leader serializes concurrent writes into a log (synchronous replication to followers trades write latency for durability; asynchronous trades the reverse). Reads can be routed to the leader (fresh, effectively single-copy) or to followers (scalable, stale). The whole scheme's correctness rests on there being exactly one leader; the dangerous states are the transitional ones — failover and partition — where a stale ex-leader might still believe it is in charge.

Tuning parameters

  • Sync vs. async replication — wait for followers to acknowledge a write (durable, higher write latency) vs. acknowledge at the leader immediately (fast, can lose the tail on leader loss).
  • Read routing — leader-only reads (fresh, no read scale-out) vs. follower reads (scalable, stale), often combined with a staleness bound.
  • Failover automation — automatic promotion (fast recovery, split-brain risk) vs. manual (safe, slow), plus how large a replication-lag gap disqualifies a promotion candidate.
  • Leadership grant — how leadership is elected and fenced so that two nodes cannot both accept writes.

When it helps, and when it misleads

Its strength is being the simplest way to get a single authoritative order for state, with no conflict resolution needed and a clear freshness story — the default of most relational databases for good reason. Its structural weaknesses are the leader itself: a write bottleneck (all writes serialize through one node) and an availability gap at failover, when writes stall until a new leader is chosen. The classic and most dangerous failure is split-brain — a partition leaves two nodes each believing they lead, both accepting divergent writes.[1] The classic misuse is async replication plus automatic failover with no fencing, so a promoted follower and a still-live old leader both take writes. The discipline is to fence leadership — a lease and a monotonic token — so at most one leader can accept a write, and to set the sync/async and failover dials against the durability the contract promises.

How it implements the components

  • replica_and_authority_topology — it defines the authority structure: one leader holds write authority, followers replicate; the topology is the mechanism.
  • write_acceptance_rule — the acceptance rule is "only the current leader may accept and order a write," which is precisely what removes write-write conflict.

It centralizes ordering rather than tolerating multiple writers — reconciling writes from several leaders is Multi-Leader Replication with Conflict Resolution's, quorum-style acceptance without a fixed leader is Quorum Read/Write Protocol's, and the fencing that stops a stale ex-leader from writing is Lease and Fencing-Token Protocol's.

References

[1] Split-brain — a partition in which two nodes each believe they are the sole leader and independently accept conflicting writes; the canonical hazard of single-leader designs. Fencing tokens and quorum-based election are the standard guards against it. ↩