Without a Leader, There Is No Consensus

Consensus is what prevents distributed systems from fracturing into multiple, conflicting realities. It ensures not just that replicas hold the same data, but in the same order, under the same history. This requires more than copying data between nodes. It requires coordination. It requires leadership.

In consensus protocols like Raft, Paxos, or Zab, the role of the leader is played by a node that proposes operations and enforces a globally consistent order, validated by a quorum. Once a majority agrees, that order becomes final. No ambiguity, no reconciliation.

Without a single coordinating point, agreement collapses into reconciliation. And that’s exactly what happens in multi-leader and leaderless designs.

Multi-Leader: When Agreement Starts to Fray

Multi-leader systems are non-consensual by design. They let every region accept writes independently. This improves availability and latency but it also means there are now multiple logs of truth.

Each leader maintains its own write history, and conflicts appear when those histories meet. Who wins? Which update came first? The answers depend on reconciliation, not consensus. Systems use Last-Write-Wins, merge logic, or CRDTs to reconcile divergent histories but what needs to be understood is that it is a repair mechanism, not agreement.

As I discussed in my previous blog, this kind of eventual convergence can still be perfectly valid and even desirable for systems that don’t need a single, globally ordered history. Reconciliation is enough for safety in value; consensus is needed only when correctness depends on the order of events.

Leaderless: From Agreement to Convergence

Leaderless systems like Dynamo, Cassandra, and Riak push this even further. Any node can accept a write; consistency emerges probabilistically through quorum reads and writes:

Write to W replicas, read from R, ensuring R + W > N for overlap.

That overlap again guarantees eventual convergence, not global order. Conflicting versions coexist until repaired.

Leaderless systems guarantee that no data is lost but not that all nodes saw the same sequence of events. They converge in value, not in history.

The Confusion: Single-Leader vs Consensus

Not all leader-based systems achieve consensus. Some only look like they do.

At first glance, single-leader replication and consensus protocols seem identical: both have a leader, both replicate writes to followers, both apply operations in order. But the difference appears the moment failure hits.

Single-Leader Replication

In a traditional single-leader replication:
• One node acts as the leader and accepts all writes
• Followers replicate the leader's WAL asynchronously or semi-synchronously
• If the leader fails, a follower is promoted, usually by an external process or coordination service such as Zookeeper, Consul, etc.

This approach is simple and performant, but it doesn't guarantee agreement on what was truly committed at the moment of failure. Followers may lag; writes may vanish. If a follower that missed the last entries becomes leader, you get divergence or data loss.

Worse, under network partitions, two primaries can emerge - a split-brain - each accepting conflicting writes. If both sides of the partition keep accepting writes, their logs diverge and must later be reconciled or manually repaired. To avoid this, many single-leader systems outsource consensus to the control plane. ZooKeeper or etcd decide which node is the real leader so that only one is ever writable at a time. But the data plane itself i.e., the actual log replication remains non-consensual. Consensus here protects leadership, not data. In other words, ZooKeeper can prevent split-brain, but it can’t prevent a stale follower from becoming leader and losing data.

Consensus-Based Replication

Consensus protocols take the same single-leader model and make it fault-tolerant and provable by bringing agreement into the data plane itself.
• The leader proposes log entries.
• Each entry is committed only after a majority of replicas acknowledge it.
• Every follower knows exactly which entries are final and which are tentative.
• If the leader crashes, a new one is elected automatically — but only a node whose log already contains all committed entries can become leader.

This eliminates both forms of uncertainty entirely i.e., the split-brain and stale-follower loss. There can never be two active leaders, because only one partition at a time can form a majority.

Here, leadership isn’t just authority — it’s proven authority. The leader isn’t trusted; it’s ratified through quorum.

What About Leaderless Consensus?

Researchers have tried to generalise consensus beyond the single-leader model. EPaxos, Mencius, and certain BFT (Byzantine Fault-Tolerant) protocols eliminate fixed leadership by allowing multiple proposers. They reach agreement on state, but not necessarily a single, global order of all operations.
• EPaxos establishes per-command dependencies — yielding a partial order of non-conflicting operations.
• Mencius rotates leadership round-robin style — effectively serialising through shared turns.
• BFT protocols distribute leadership across phases but still rely on quorum voting to finalise commits.

So yes — leaderless consensus exists, but only by relaxing what “consensus” means: you get agreement on outcome, not necessarily on timeline.

That’s why in practice, almost every production-grade consensus system still keeps a leader, not as a bottleneck, but as a synchronisation point. Without leadership, you may achieve agreement on state, but never on a single, total order of history.