Skip to content
The Data EngineeringThe Data EngineeringBeta
About
Main content

Leader election and epochs: one mechanism, many names

What does election guarantee, and why is one monotonic number behind every term, epoch and ballot?

Election has a deliberately modest specification: at most one per term, always; at least one leader, eventually.

  • The first half is . It comes from intersection plus one vote per term: two majorities of the same membership share a voter, and that voter cannot vote twice. No timing is involved.
  • The second half is , and it needs symmetry breaking, because simultaneous candidates split the vote (nobody gets a majority). Randomized election are the fix. Each node waits a random time (for example 150–300 ms) before it becomes a candidate, so one usually starts first and wins. This is the first of three appearances of the idea "randomization substitutes for coordination" in this article.

The term (Raft), (ZAB, Kafka), generation stamp (HDFS), ballot number (Paxos), view (Viewstamped Replication) and (lock services) are one mechanism wearing six names. It is a monotonically increasing integer, agreed by a quorum, stamped on every subsequent action, and checked on arrival. Its function is to convert a question about time ("is this message from the current leader?") into a question about order, which needs no clock and no synchrony. This is the recurring trade of this whole mechanism: order is cheaper to agree on than time. Wherever you see a timing argument in a safety proof, look for the counter that should have replaced it. The shard-map epoch of resharding is the same mechanism applied to ownership instead of leadership.

Two practical results follow from taking the definition seriously.

  1. Failover latency is set by the detector, not by the consensus algorithm. Detection takes hundreds of milliseconds to seconds; the election round takes one ; catch-up depends on how much the logs differ. Arguing about Raft versus Paxos election speed is arguing about the small term.
  2. A node that is partitioned away keeps timing out and so keeps increasing its term. When it rejoins, its higher term deposes a perfectly healthy leader. Raft's PreVote (a candidate first asks whether it would win, without raising its term), ZAB's epoch validation and etcd's check-quorum all exist to suppress exactly this. That they converge on the same fix is the evidence: a disruptive candidate is the dominant real-world availability bug in leader-based systems, not the failure the election was designed for.

Compression: election is the cheapest possible agreement (at most one, eventually one), and the term is what converts "is this current?" from a timing question into an ordering one.