Joint-Consensus Membership Change¶

Membership-change protocol — instantiates Assumption-Bounded Distributed Agreement

Changes the set of participants without ever letting the old and new memberships form two independent majorities — by routing the switch through a transitional joint configuration that requires agreement from both.

Consensus is safe only while quorums intersect — but the participant set itself sometimes has to change, and changing it is where intersection is most easily broken. Joint-Consensus Membership Change is the protocol that adds, removes, or replaces participants in a running agreement group without a moment of unsafety. Its defining move addresses the specific hazard of reconfiguration: a split brain in which, mid-switch, the old configuration and the new one each independently reach a majority and decide conflicting things. The protocol closes that window by inserting an intermediate joint configuration in which every decision requires a majority of both the old and the new memberships simultaneously. Because no decision can be made without overlap across the two sets, the two configurations can never diverge; only once the joint configuration is itself committed does the group advance to the new-only membership. In doing so it resizes the redundancy pool and re-draws the decision-authority boundary without ever opening a gap.

Example¶

An operations team needs to grow a replicated coordination cluster from three nodes to five — live, to raise its fault tolerance, with no downtime. The naive approach (edit each node's config and restart) risks a window in which the old three (majority = 2) and the new five (majority = 3) could each elect a different leader and accept conflicting writes. Joint consensus removes the window. The cluster first agrees, through its normal commit path, on a joint configuration in which every decision must satisfy both "2 of the old 3" and "3 of the new 5." In that state a would-be split leader cannot win, because it cannot assemble both majorities at once. Once the joint configuration is committed, the cluster commits the final new-only configuration, and the two added nodes become full voters. The cluster went from three to five with no split-brain, no downtime, and no lost decision.^[1]

How it works¶

Route through the joint state. The transition never jumps old→new directly; it passes through a joint configuration whose decisions need overlapping majorities in both memberships, which is what forbids two independent quorums.
Reconfigure via the agreement path itself. Each configuration change is proposed and committed like any other value, so it inherits the same commit safety rather than needing a separate mechanism.
Move one step at a time. Changes are applied incrementally (a single joint step, or one server at a time), keeping the required overlap between successive memberships.
Shift authority only at commit points. Who is entitled to vote changes exactly when a configuration commits — never in the ambiguous space between.

Tuning parameters¶

Joint-config vs. single-server steps — the full joint-consensus dance for arbitrary changes, or a simpler "add/remove one at a time" rule that avoids an explicit joint configuration. Single-server steps are easier to reason about but only cover incremental changes.
Catch-up (learner) phase — whether a new node first replays state as a non-voting learner before being enfranchised. Longer catch-up avoids admitting a voter that cannot yet respond, at the cost of a slower rollout.
Change rate — one change at a time versus batching several. Batching is faster but strains the overlap guarantee.
Removed-node handling — whether a removed leader steps down immediately and whether departed nodes are actively demoted, to stop a stranded ex-member from disrupting the group.

When it helps, and when it misleads¶

Its strength is that it is the only safe way to reconfigure a live quorum system: it preserves quorum intersection across the very operation most likely to destroy it, so a cluster can grow, shrink, or replace hardware without stopping and without risking two histories.

Its subtleties bite the unwary. Admitting a not-yet-caught-up voter can lower availability — it counts toward the quorum size but cannot yet usefully respond — which is why the learner phase exists. Removing nodes can strand a partitioned minority that still believes it is a member. And a mis-ordered change that skips the joint step and jumps straight from old to new reintroduces exactly the split-brain the protocol exists to prevent. The classic misuse is bulk-swapping many members at once to "save time," which breaks the overlap between successive configurations. The discipline is to change membership incrementally, catch new nodes up before enfranchising them, and always route the switch through the safe intermediate — never around it.

How it implements the components¶

participant_and_membership_model — it owns the live, versioned set of participants and the rules by which that set may legally change.
decision_authority_boundary — it re-draws who is entitled to vote and decide as membership shifts, moving the boundary only at committed transition points.
redundancy_pool — it grows or shrinks the pool of replicas providing fault tolerance, thereby adjusting the group's failure budget.

It does not perform the individual quorum commit each change rides on (that is Quorum or Consensus Commit), keep the replicated log the configuration entries live in (Raft-Style Replicated-Log Protocol / Write-Ahead Vote Log), or elect the leader that drives the change (Term/Epoch Leader Election).

Instantiates: Assumption-Bounded Distributed Agreement — it keeps the agreement's safety invariant intact across changes to the participant set.
Consumes: Quorum or Consensus Commit — every membership transition is itself agreed through an ordinary quorum commit.
Sibling mechanisms: Quorum or Consensus Commit · Raft-Style Replicated-Log Protocol · Timeout Policy · Byzantine Fault-Tolerant Quorum Protocol · Consensus Fault-Injection Test · Heartbeat and Suspicion Detector · Paxos-Style Quorum Protocol · Randomized Common-Coin Protocol · Signed Quorum Certificate · Term/Epoch Leader Election · View-Change Protocol · Write-Ahead Vote Log

Notes¶

There is an availability subtlety worth stating plainly: a freshly added voter that has not caught up counts toward the quorum size but cannot yet vote usefully, so an unstaged addition can reduce availability until it is current. This is exactly why the learner/catch-up phase precedes enfranchisement — the node earns its vote only after it can actually cast one.

References¶

[1] Joint consensus is the membership-change technique introduced with Raft (Ongaro and Ousterhout): during a configuration change, agreement requires overlapping majorities in both the old and new configurations, which guarantees the two can never make conflicting decisions independently. ↩