Joint Consensus Reconfiguration¶
Protocol — instantiates Fault-Tolerant Distributed Consensus
Changes the voting membership through an overlap phase so old and new configurations can never decide independently.
Changing who votes is the most dangerous moment in a consensus system, because for an instant there are two candidate electorates. If the old set and the new set are ever both allowed to decide on their own, they can commit conflicting values and split the system in two. Joint Consensus Reconfiguration removes that window by never letting one configuration hand off directly to another. Instead it introduces a joint transition state in which a decision requires the approval of both the old and the new quorum simultaneously. Only after that joint state is durably committed — proving both electorates are moving together — does the system advance to the new configuration alone. Its defining property is overlap by construction: at no point in the change is there a quorum that can decide without an overlapping quorum of the other configuration also agreeing, so the two memberships can never diverge.
Example¶
A company runs a three-node replicated database in a single region and needs to migrate to five nodes spread across three regions, without ever taking a write outage and without risking a split. A naive edit — swap the config files and restart — could briefly leave the old three-node majority and the new five-node majority each able to commit, so a network hiccup during the swap could produce two conflicting histories. Instead the operators run a joint reconfiguration. The current leader proposes a joint configuration naming both the old three and the new five as voters; while it is active, every commit needs a majority of the old three and a majority of the new five. The two new region replicas first install a certified snapshot and catch up on the log suffix so they can vote safely. Once the joint configuration is durably committed and the newcomers are ready, the leader proposes the new-only five-node configuration; committing that entry — again under the joint rule — activates the five-voter epoch and fences the two departing nodes out of the electorate. Throughout, there was never a moment when three old nodes or five new nodes could decide alone: the overlap held the two electorates together across the entire migration.
How it works¶
- Validate and compute geometry. Check the requested change and calculate both the old and new quorum requirements for the transition.
- Commit the joint state. Propose a configuration that includes both memberships; while joint, every decision needs a quorum from each — this is the overlap that prevents divergence.
- Prepare the newcomers. Have joining nodes install a certified recovery point and replay the log suffix before they are trusted to vote.
- Commit new-only and fence. After readiness, commit the new-only configuration under the joint rule, activate the new epoch, and fence removed voters from all future evidence.
Tuning parameters¶
- Transition granularity — how many voters change per transition. One-at-a-time changes are simplest to reason about and keep availability high; larger swaps are faster but tighten the joint-quorum requirement.
- Catch-up gate strictness — how far behind a joining node may be before it votes. A strict gate prevents an unready node from weakening the new quorum but delays the transition.
- Concurrency policy — whether more than one reconfiguration may be in flight. Serializing to one governed transition at a time is the safe default; concurrent transitions demand a formal proof of non-interference.
- Fencing horizon — how aggressively removed voters are cut off. Firm fencing blocks a departed node from ever counting again but requires propagating the new epoch everywhere before removal completes.
When it helps, and when it misleads¶
Its strength is preserving authority continuity through membership change — supporting rolling replacement, region migration, and node repair with an explicit audit path and no split. It is the disciplined answer to "how do we change the cluster while it is serving traffic," realized in systems that adopted the joint-consensus approach.[1]
Its cost is that the joint phase is temporarily stricter: needing both quorums lowers availability during the transition, and a botched catch-up can stall it. The classic misuse is skipping the joint phase under urgency — doing a one-step replacement because the change "seems small" — or activating a voter that has not caught up, either of which reopens the split-brain window. The guarding discipline is one governed transition at a time, a durable completion marker for each step, and treating the joint quorum as non-negotiable even when operators are in a hurry.
How it implements the components¶
membership_configuration— it makes the voter set, its epoch, and the active transition state explicit and versioned, so every certificate names a governed electorate.recovery_and_reconfiguration_rule— it defines snapshot install, log catch-up, and old/new overlap so joining and departing nodes change roles without losing certified history.quorum_and_intersection_policy— it applies the combined old/new quorum during the joint phase, the overlap that keeps the two configurations from deciding independently.
It does not implement protocol_phase_and_message_state or the leader_or_coordinator_epoch — the per-decision phase machine belongs to Replicated Log Consensus Engine and coordinator selection to Leader Election and Term Protocol; this protocol changes the electorate those mechanisms run within.
Related¶
- Instantiates: Fault-Tolerant Distributed Consensus — the membership-transition mechanism.
- Consumes: Replicated Log Consensus Engine commits the joint and new-only configuration entries this protocol proposes.
- Sibling mechanisms: Replicated Log Consensus Engine · Leader Election and Term Protocol · Authenticated Vote Certificate · Crash-Fault Quorum Protocol
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The executable overlap phase controls voting state so old and new configurations cannot decide independently during membership change.
Nearest alternative: Protocol, Workflow & Routine — Reconfiguration follows stages, but runtime consensus enforcement is the defining form.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed-consensus protocols developed overlap phases requiring old and new quorums during safe reconfiguration.
Review outcome: Independent reviewer agreement; high confidence.
References¶
[1] The Raft consensus algorithm (Ongaro & Ousterhout, 2014) popularized joint consensus for membership change: a transitional configuration requiring agreement from both the old and new voter sets before the new set operates alone — the overlap discipline this mechanism describes. withdrawn registry ↩