CONCEPT Cited by 3 sources

Elector¶

Definition¶

An elector is an agent permitted to run the leadership-change protocol (detect failures, revoke the prior leader, establish a new one). The elector role is distinct from the candidate role — a candidate is a node eligible to become leader — though in simple designs one node plays both. Sugu Sougoumarane introduces the elector vocabulary precisely to enable taxonomic reasoning about leadership-change protocols at scale:

"It is not necessary for a candidate to elect itself as leader. A separate agent can perform all the necessary steps to promote a candidate as leader. We will call this the elector. In many situations, like in the case of YouTube, this separation may be necessary. Unsurprisingly, Vitess has also inherited this separation: VTorc is a Vitess component that acts as the elector." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races)

Why the split exists¶

When the candidate pool is large and the elector pool need not be, collapsing them leads to unnecessary work. Sugu's YouTube example:

"At YouTube, each shard had fifteen eligible primaries. Having all of them scan for failures and perform active failovers was not practical. Instead, we had one agent in each region that scanned for failures and also performed leadership elections."

15 candidates per shard × N shards is a lot of MySQL replicas doing failure-scanning work that one elector per region can do instead. The elector role is also positioned differently in the network topology — YouTube's per-region elector can have different RPC visibility than any given MySQL replica.

Why there must be more than one elector¶

Running with exactly one elector agent fails under network partition:

"If we had only one agent that performed leadership changes, there would be no reason to worry about races. But this is not practical because a network partition could isolate that agent and prevent it from performing the necessary actions. Introducing more than one agent to perform leadership changes requires us to handle race conditions."

Multiple electors → races → the need for the lock-based (patterns/lock-based-leader-election) vs lock-free (patterns/lock-free-leader-election) taxonomy.

Canonical instance: VTOrc¶

VTOrc is Vitess's named elector component — a Vitess binary that scans for MySQL primary failures and initiates active failovers by acquiring a Vitess-topology lock (via etcd) and running the revoke/establish protocol against the shard's replica set. Multiple VTOrcs are deployed per cluster; they race for the etcd lock on any given leadership change.

Relation to "soft" leader election¶

The elector concept sits in the hard (protocol-based) leader-election family. The soft form (concepts/soft-leader-election, from Dicer) routes keys to pods via affinity without running any protocol — there is no separate elector role at all because there is no protocol. Use soft leader election when brief double-ownership is tolerable; use hard leader election (with electors) when exclusive ownership is required.

Seen in¶

sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts — Part 8 capstone re-affirms the elector role and discloses a VTOrc full-auto-pilot roadmap: "There are still a few corner cases that may require human intervention. We intend to enhance vtorc to also remedy those situations. This will put Vitess on full auto-pilot." Part 8's four-advantage argument for lock-based over lock-free at scale is structurally about electors: (1) the elector can ask the current leader to step down gracefully; (2) the elector can coordinate node membership changes through the lock; (3) the elector maintains a stable published leader for direct-to-leader consistent reads; (4) the elector enforces anti-flapping rules. All four advantages are elector-mediated and only possible when the elector is operating on a stable-leader substrate.
sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests — canonical wiki extension: Part 7 canonicalises the elector's role in request propagation — reaching enough followers to simultaneously revoke the old leader and discover previously-completed requests. Also names VTOrc as a customised fork of Orchestrator (architectural-lineage disclosure not previously in the wiki). Elector capability invariant: "An elector must be able to reach a sufficient number of followers to revoke the previous leadership. If this is not possible, the elector is blocked."; conversely, "An elector need not (and may not be able to) reach all the followers of a leader." — structurally incomplete knowledge is what creates the seven propagation failure modes.
sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races — canonical wiki introduction of the elector/candidate split; YouTube and Vitess/VTOrc as the motivating examples.