Raft Membership Changes and Joint Consensus

By the end of this lesson, you will be able to...

• Explain why changing voters changes the safety argument, not merely cluster metadata.

• Trace the joint-consensus transition from an old configuration to a new one.

• Identify why a configuration entry must be committed through the log before it changes authority.

Idea in one sentence: Raft changes membership through a joint configuration that requires both the old and new quorums, so authority cannot jump between two non-overlapping majorities.

Core Insight

A five-node Raft cluster must replace two machines. The simple plan is tempting: update the voter list from {A,B,C,D,E} to {C,D,E,F,G}, then let the new list take effect immediately.

That plan treats membership as ordinary configuration. It is not. Membership defines which acknowledgements elect leaders and commit log entries. If some servers use the old rule while others use the new one, two groups can each obtain what looks locally like a majority and direct incompatible histories.

Raft prevents that abrupt authority change with joint consensus. It first commits a configuration that contains both old and new voter sets. While this joint configuration is active, a decision needs a majority of the old set and a majority of the new set. Only after that joint configuration is committed does the leader append the final new configuration, which then commits under the new configuration's quorum rule.

The extra step is not ceremony. It is the bridge that preserves quorum overlap while the definition of a quorum changes.

The Small Situation: Majorities Can Stop Intersecting

Use a deliberately small example:

old configuration: {A, B, C}
new configuration: {C, D, E}

In the old configuration, {A,B} is a majority. In the new configuration, {D,E} is a majority. These two groups do not overlap.

old majority: A B
new majority:     D E
overlap: none

If A,B can still elect or commit under the old rule while D,E can already do so under the new rule, no acceptor bridges the two claims. The system has recreated the split-authority shape consensus was meant to avoid.

The problem is not that the old and new sets share C. Different servers can learn a configuration entry at different times, leaders can fail mid-change, and partitions can isolate the shared server. The protocol needs a rule that makes every committed transition carry evidence from both authority systems.

The Initial Model: Commit the New Voter List Once

We might say: “Put the new voter list in the log. Once a majority commits it, everyone switches to the new rule.” This works only if every relevant server changes its interpretation at the same instant, which a distributed system cannot assume.

The pressure appears during propagation. Some nodes may already be using the new list; others may still be communicating under the old list. A server cannot infer from silence whether a peer has applied the configuration, is slow, or is unreachable. A leader crash at this point makes the ambiguity worse.

The missing model is a period where no side may act alone. Joint consensus supplies that period.

The Mechanism: Commit a Bridge Before the Destination

Plain meaning: Before retiring old voters or trusting new voters alone, require a decision that the old authority and new authority both recognize.

In this scenario: The leader first appends C_old,new, then commits it under joint rules. It next appends C_new; that entry commits under the new configuration's rule. Only then is the new configuration the sole quorum rule.

Technical name: Raft calls this joint consensus. The joint configuration is the temporary voter set whose commit and election decisions require separate majorities of both configurations.

The transition

1. old configuration C_old is active
2. append and commit joint configuration C_old,new
3. operate using both old-majority and new-majority evidence
4. append C_new and commit it with a C_new majority
5. operate using only the new-majority rule

During step 3, the combined configuration is not “all nodes must reply.” It is stricter and more precise:

commit or election evidence
  = majority(C_old) AND majority(C_new)

This requirement means any successful decision crosses the transition boundary. A quorum from the old configuration alone is insufficient; a quorum from the new configuration alone is insufficient.

Configuration entries are log entries. They are replicated, committed, and applied using the same evidence boundary as other commands. A leader cannot safely treat an out-of-band administrative edit as equivalent to a committed membership change.

Worked Trace: Replace Two Voters Without Two Authorities

The larger transition is:

C_old = {A, B, C, D, E}
C_new = {C, D, E, F, G}

Both sets use quorums of three. C,D,E overlap, but the leader still follows the joint protocol because membership knowledge is not instantaneous.

Step 1: commit the joint configuration

Leader C appends a log entry declaring C_old,new. It replicates the entry until both requirements hold:

The acknowledgements overlap here, but overlap is not required to be the same physical reply set. What matters is that the collected evidence contains an old majority and a new majority. Servers that add the joint entry begin using its rules; once it is committed, the joint configuration is the authoritative bridge for the next step.

Step 2: a failure during the joint period

Suppose C crashes after C_old,new committed but before the final configuration. A new leader must be elected under the joint rule. Candidate D cannot win with votes only from old voters A,B,D; it also needs a new-side majority. It cannot win with only new voters D,F,G; it also needs an old-side majority.

This feels slower because it is stricter. That is the point. Neither half can claim exclusive authority while the log says the cluster is changing its quorum system.

The same rule applies to committing ordinary entries during this period. An entry accepted only by A,B,D is not committed, even though that is an old majority. An entry accepted only by D,F,G is not committed either. It needs evidence satisfying both configurations.

Step 3: commit the final configuration

The elected leader appends C_new = {C,D,E,F,G}. Because the committed joint entry makes this transition safe, the final entry is committed with a majority of C_new. After that commit, only C_new defines election and commit majorities.

for the joint entry: old majority AND new majority
for the final C_new entry: C_new majority
after final commit: new majority only

So far: joint consensus makes the definition of authority change through an authoritative history. A leader change or a delayed configuration message cannot let two non-overlapping majorities skip that bridge.

What This Changes Operationally

Before joint consensus, an operator may imagine adding or removing voters as an atomic control-plane edit. After it, the important question is: “Which configuration entry is committed, and which quorum rule is active for this log position?”

This changes safe operational behavior. A new node usually needs to catch up before relying on it as a voter; otherwise it can make elections and commit progress harder. Operators should avoid stacking changes while one transition is incomplete. They should also distinguish a learner or non-voting replica from an active voter: receiving the log is useful, but voting changes the proof obligation.

These are situated operational preferences, not claims that every Raft implementation exposes identical APIs. The invariant is stable: a change to who counts must be committed under rules that preserve a bridge from the old authority to the new one.

Trade-offs, Limits, and Signals

Joint consensus improves safety during configuration change. The trade-off is extra log entries, stricter temporary quorum requirements, and more ways for a change to wait on lagging or unavailable voters.

It helps when the system can still contact an old majority and a new majority. It can stall when a partition leaves only one side reachable, when a newly added voter is too far behind, or when leadership churn prevents either configuration entry from committing. Safety can hold while the membership operation makes no progress.

Useful signals are a configuration entry that remains uncommitted, election attempts that cannot satisfy both majorities, growing replication lag on prospective voters, and repeated leader changes during the joint phase. These signal a progress boundary; they do not justify bypassing the joint rule.

Joint consensus also does not solve disaster recovery, data loss, or client-facing API design. Those decisions require later lessons. Its narrow job is to prevent membership change from creating two independent definitions of legitimate quorum evidence.

Common Confusions

Confusion: “The new configuration is safe as soon as one server receives it.”

Why it is tempting: A configuration is a small, readable value.

Better model: It changes quorum authority, so it becomes active only through the protocol's committed transition.

Confusion: “Joint consensus requires every old and new server.”

Why it is tempting: The joint set contains all of them.

Better model: It requires a majority of each configuration, not unanimous acknowledgement.

Confusion: “A majority from either side is enough during the transition.”

Why it is tempting: Each side has a familiar majority rule.

Better model: The joint period deliberately requires both. That is how it prevents old-only and new-only authority from diverging.

Check Your Understanding

Check: During a joint configuration, an entry has acknowledgements from an old majority but not a new majority. Is it committed?

Think first, then reveal.

Answer: No. The joint rule needs both an old-configuration majority and a new-configuration majority. The missing new-side evidence means the entry remains tentative.

Check: Why is it unsafe to switch directly between {A,B,C} and {C,D,E} even though both configurations contain C?

Think first, then reveal.

Answer: Old majority {A,B} and new majority {D,E} do not intersect. During asynchronous propagation, each group could otherwise act under a different rule without a shared voter carrying evidence between them.

Practice: Review a Membership Plan

A service moves from {A,B,C,D,E} to {B,C,D,F,G}. The operator proposes: add F,G as immediate voters, remove A,E, and restart the leader if the change seems slow.

Write a safer sequence. Your answer should name the joint configuration, the quorum rule while it is active, the final configuration, and one signal that should make the operator pause rather than force progress.

Model answer: First catch up F,G as non-voting replicas where the implementation supports that role. Then append and commit C_old,new; while it is active, require a majority of old voters and a majority of new voters for elections and commitment. Append C_new only after that joint entry is committed, then commit C_new with a new-configuration majority and retire A,E from the active voter set. Pause if the joint configuration cannot commit, if follower lag is growing, or if leader churn prevents the required quorum evidence. Restarting a leader does not bypass the quorum proof.

Connections

The previous lesson separated replicated, committed, and applied states. Joint consensus extends that reasoning: configuration is also a log value, but it changes the quorum rule that makes later entries committed.

The next lesson compares this leader-recovery and ordering problem with ZooKeeper's ZAB protocol. The vocabulary changes, but the recurring requirement remains one recoverable authoritative history after failure.

Resources

• [PAPER] In Search of an Understandable Consensus Algorithm — Focus: read the membership-change section for its joint-majority rule and the reason configuration changes use the log.
• [DISSERTATION] Consensus: Bridging Theory and Practice — Focus: use the extended discussion to distinguish the invariant from implementation-specific operational choices.
• [DOC] The Raft Consensus Algorithm — Focus: find the official paper and supporting explanations before mapping the rule to a particular system.

Key Takeaways

• Membership determines which votes and acknowledgements count, so it is part of consensus safety.
• A direct switch can expose non-overlapping old and new majorities; joint consensus preserves a bridge.
• During the joint phase, elections and commitment require a majority of both configurations.
• Configuration entries must be replicated and committed through the log before they change authority.
• The safety cost is stricter temporary availability and a slower, more observable transition.