Skip to content

CONCEPT Cited by 2 sources

Leader revocation

Definition

Leader revocation is the act of invalidating the conditions that allow a leader in a single-leader distributed system to complete requests. After revocation, the previous leader can no longer propagate writes even if it is still alive and believes itself to be the leader. Revocation is structurally paired with establishment, and in a correct protocol revocation must precede establishment — otherwise two nodes can simultaneously satisfy the leadership invariant and the at-most-one-leader property breaks.

Why it was hidden in traditional algorithms

In majority-quorum consensus algorithms (Paxos, Raft), revocation and establishment are achieved by the same atomic action: pushing a new proposal number to a majority of followers simultaneously disables the old leader (followers reject its now-stale proposal number) and enables the new one. Because the two concerns were bundled into one protocol step, the literature treated them as inseparable (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-4-establishment-and-revocation).

Sougoumarane's load-bearing claim: "Because the revoke was implicitly achieved, it was never called out as a separate concern. More importantly, it was never called out as a concern that could be separated." Once you recognise revocation as a separable step, you can use different mechanisms for it on different failure-mode axes.

Revocation mechanisms

Any mechanism that makes the establishment condition false for the old leader is a valid revocation:

  • Proposal-number push (Paxos, Raft) — followers reject stale proposal numbers.
  • Replication-source change (MySQL semi-sync) — point the replica at a different primary, or tell it to stop replicating. The old primary can no longer get acks.
  • Graceful step-down — ask the current leader to stop accepting writes (planned changes only; requires the leader to be reachable and cooperative).
  • Follower fencing — tell the followers to stop accepting writes from the current leader (used when the leader is unreachable — crash or partition).
  • Physical / network isolation — cut the network cable, shut down the machine. The canonical Google anecdote: "I know of one incident at Google where we had to dispatch a human to physically shut down a machine where a leader had gone rogue."

Each mechanism has a different reachability assumption:

Mechanism Requires leader reachable? Common use
Graceful step-down Yes Planned software rollouts
Proposal-number push No General consensus
Replication-source change Yes (for target) MySQL / Postgres failover
Follower fencing No Crash / partition
Physical isolation No Rogue-leader last resort

Reachability determines the mechanism

  • Leader known and reachable → graceful step-down is preferred (application sees no errors when composed with lameduck + query buffering).
  • Leader unreachable / unresponsive → must revoke against all potential leaders (fence enough followers that no leader can complete writes).

Sougoumarane's rule: "If so, the revocation must be performed against all potential leaders. In other words, the election process must reach enough nodes to be sure that no existing leader can complete their requests." The lower bound on who-must-be-reached is determined by the establishment invariant, not by majority-quorum arithmetic.

Revocation mechanisms are interchangeable across rounds

Two revocation algorithms can be mixed in a composite system: "Let us assume that a leadership is established by satisfying conditions A and B. One algorithm achieves revocation by making condition A false, and the other by making condition B false. In both cases, it is a successful revocation. Once revocation is complete, both algorithms have to make conditions A and B true for the new leader, which will allow for subsequent rounds to use any method of revocation." The invariant is what needs to hold — not the specific path taken to re-satisfy it.

Seen in

Last updated · 347 distilled / 1,201 read