CONCEPT Cited by 3 sources

Revoke-and-establish split¶

Definition¶

The revoke-and-establish split is the pedagogical decomposition, from Sugu Sougoumarane's Consensus algorithms at scale series, of a leadership change into two independently-designable concerns:

Revoke — invalidate the prior leader so no stale-leader writes can still commit.
Establish — commit the new leader so clients and followers converge on it.

Sugu's framing:

"We conceptualized the leadership change process into two distinct concerns: Revoke and Establish. This opens up more implementation options that previous traditional algorithms did not accommodate." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races)

Traditional consensus algorithms (Paxos, Raft) fuse revoke + establish into the same majority-quorum round-trip. Sugu's argument is that factoring them apart exposes design space — different race-resolution strategies, different coordination substrates, different timeout regimes — that the fused formulation hides.

Why the split matters¶

Factoring the two concerns lets you mix-and-match the mechanisms that implement them:

Race resolution (who wins when two electors try at once) is its own concern, layered on top of revoke + establish; see patterns/lock-based-leader-election vs patterns/lock-free-leader-election.
Lock acquisition (the primitive that gates revoke + establish) can be the same quorum used for revoke/establish (Raft's implicit lock) or an external coordinator entirely (patterns/external-coordinator-for-leadership-lock — e.g. Vitess using etcd as the lock substrate for its Vitess-topology leadership).
Propagation (telling clients and followers about the new leader) is yet another concern on top of both; covered in Part 7 of Sugu's series — see concepts/request-propagation for the full treatment and patterns/version-per-request-to-resolve-conflicts for the resolution pattern.

The two lock-family decompositions¶

Lock-based Revoke/Establish¶

Acquire lock (the "race-winner picker")
Revoke prior leader (ensure no stale writes)
Establish new leader (commit the new primary)
Release lock (explicit or via time-bounded lease)

Raft is the implicit lock-based instance: a winning elector's majority-quorum acks constitute both the lock and the revocation of any smaller-quorum older leader.

Lock-free Revoke/Establish¶

Pick a new proposal number / term strictly greater than anything observed.
Send revoke-with-proposal-number to all potential candidates (not just the known leader).
Send establish-with-proposal-number to the chosen candidate.
Followers remember the highest number seen and reject anything lower.

Paxos is the canonical lock-free instance via proposal numbers.

Canonical instance: Vitess¶

Vitess uses the split explicitly: the race-resolution layer is an etcd-backed lock (so the fast path is lock-based), but the actual revoke/establish of the MySQL-primary role is a Vitess-internal operation that can use PROMOTE / DEMOTE MySQL primitives and VReplication catch-up. "In Vitess, we use an external system like etcd to obtain such a lock. The decision to rely on another consensus system to implement our own may seem odd. But the difference is that Vitess itself can complete a massive number of requests per second. Its usage of etcd is only for changing leadership, which is in the order of once per day or week."

Seen in¶

sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts — Part 8 capstone re-frames the split as the foundational generalisation over Paxos/Raft: "We have reconceptualized a leadership change as a two-step process: revocation and establishment. Intersecting quorums are only one way to achieve this goal. We have shown situations where you could achieve a leadership change by directly asking the previous leader to step down. … This approach does not require knowledge of intersecting quorums." Graceful-demotion explicitly "does not require knowledge of intersecting quorums" — the split sidesteps the protocol altogether for planned changes. Multiple revocation methods are interoperable on the same cluster (graceful for planned, quorum-revocation for failures). The split composes with the two Part-8 architectural recommendations: patterns/pluggable-durability-rules (durability as a plugin over node-set predicates) + patterns/lock-based-over-lock-free-at-scale (four-advantage argument).
sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests — canonical wiki extension: Part 7 adds propagation as the third concern that layers on top of the revoke/establish split (Parts 5 canonicalised race resolution as the second). The graceful-propagation-before-demotion pattern (patterns/graceful-propagation-before-demotion) extends the Part-4 graceful-demotion path with a propagation-completion invariant; the failure-driven path reuses the fencing primitive to simultaneously revoke and discover durable requests. Canonical wiki datum: revocation and discovery compose into one protocol step in the failure-driven regime.
sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races — Sugu Sougoumarane canonicalises the split and uses it as the organising frame for the whole series. Part 5 specifically analyses how race resolution layers on top.