Distributed Systems

Leader Election in Distributed Systems: Raft and Paxos at a High Level

Every replicated database and cluster coordinator — etcd, ZooKeeper, most Raft-based systems — has exactly one node making decisions at a time. Getting a cluster of independent machines to agree on who that node is turns out to be one of the genuinely hard problems in distributed computing.

Published July 6, 2026

A single-leader replicated system needs one node accepting writes and coordinating everyone else, because letting multiple nodes accept conflicting writes independently is how you end up with two answers to "what's the current value of this key." The hard part isn't picking a leader when everything is healthy — it's picking one, and staying in agreement about who it is, when nodes crash, network links partition, and messages arrive late or out of order. That's the problem consensus algorithms solve, and Paxos and Raft are the two names that come up constantly, because between them they cover almost every production system that needs this.

Why you can't just pick the first node that answers

The obvious naive approach — the first node to say "I'm the leader" becomes the leader — breaks the instant you have a network partition. Split a five-node cluster into a group of three and a group of two, and if each side independently elects its own leader, you get two nodes both believing they're in charge, both accepting writes, and both diverging from each other. This is split brain, and it's the scenario every real consensus algorithm is specifically designed to make impossible, not just unlikely.

Raft: terms, votes, and majority

Raft was designed explicitly to be more understandable than Paxos, and it organizes time into numbered terms. In each term, a node can be a follower, a candidate, or the leader, and there's at most one leader per term. A follower that stops hearing from a leader (its election timeout expires, meaning no heartbeat arrived) becomes a candidate, increments the term number, and requests votes from every other node:

state = FOLLOWER
term = 0

on election_timeout:
  state = CANDIDATE
  term += 1
  votes = 1  // vote for self
  request_vote(term, my_last_log_index) to all peers

on receive_vote_granted:
  votes += 1
  if votes > cluster_size / 2:
    state = LEADER
    send_heartbeats()

A node grants its vote at most once per term, and only to a candidate whose log is at least as up to date as its own — that constraint is what keeps a node with stale, missing writes from becoming leader and overwriting more current data. Because a vote requires a strict majority and each node votes once per term, at most one candidate can win any given term: two candidates can't both collect a majority of the same finite set of votes. In the split-brain scenario above, the group of two can never elect a leader, because two votes out of five isn't a majority. Only the group of three can, so exactly one side of the partition keeps functioning, and the other correctly stops accepting writes until the partition heals. That's not a side effect — it's the entire mechanism working as designed.

Where Paxos differs

Paxos, from Leslie Lamport's original 1998 paper, solves the same underlying problem — getting a majority of nodes to agree on a single value despite failures — but does it without Raft's simplifying structure of terms and a single elected leader coordinating log replication. Basic Paxos reaches agreement on one value per full run of the protocol through two phases (prepare/promise, then accept/accepted), and building a continuously operating replicated log on top of it (Multi-Paxos) requires extensions the original paper leaves as an exercise, which is a large part of why Paxos earned a reputation for being difficult to implement correctly. Raft was published specifically to address that gap: the same safety guarantees, with an explicit, continuously elected leader and a much more prescriptive algorithm for log replication, which is why almost every consensus library written in the last decade (etcd's raft package, HashiCorp's raft implementation used in Consul, CockroachDB's replication layer) is Raft-based rather than Paxos-based.

What this buys a system, and what it costs

The direct payoff is safety under partition and failure: a Raft-based cluster never has two leaders in the same term, and a majority of nodes has to be reachable and agree before any write is considered committed, which is exactly the kind of guarantee the CAP theorem describes as choosing consistency over availability during a partition. The cost is that a cluster needs a majority quorum to make progress at all — a five-node Raft cluster tolerates two node failures and keeps working, but lose three and the whole cluster stops accepting writes rather than risk disagreement, even though two nodes are still up and healthy. That's a deliberate trade against systems like consistent hashing-based leaderless designs, which sacrifice strict ordering guarantees to keep accepting writes through partitions that would stall a Raft cluster entirely. The Raft paper's own website, raft.github.io, has an interactive visualization that's worth spending ten minutes with if the term/vote mechanics above still feel abstract.