Explain joint consensus and how it makes single-voter membership changes safe in KRaft.

## The problem membership change creates Raft safety rests on **majority overlap**: any two majorities of the same voter set share at least one member, so a newly elected leader always sees the latest committed entry. But when the **voter set changes**, replicas switch from the old set (`C_old`) to the new set (`C_new`) at slightly different times. During that window, two *different* configurations are active across the cluster. If elections could complete using only `C_old` on some nodes and only `C_new` on others, you could elect **two leaders simultaneously** from **disjoint** majorities — a split brain that violates safety. ## Joint consensus (the general mechanism) The original Raft paper solves this with **joint consensus**. The leader appends a special configuration log entry that puts the cluster into a **joint configuration `C_old,new`**. While in this joint state: - **Log entries are committed** only when replicated to a majority of `C_old` **AND** a majority of `C_new`. - **Leader elections succeed** only with votes from a majority of `C_old` **AND** a majority of `C_new`. Because every decision requires *both* majorities, the old and new worlds cannot independently elect leaders or commit conflicting entries — the dual requirement forces overlap across the configurations. Once the `C_old,new` entry is committed, the leader appends a second entry for `C_new` alone; when that commits, `C_old` is retired and the system runs on the new set. ## KRaft's choice: one server at a time KRaft (KIP-853) deliberately limits reconfiguration to **adding or removing a single voter per change**. The single-server change is the well-known special case where `C_old` and `C_new` differ by exactly one member, so a majority of one **always intersects** a majority of the other — overlap is guaranteed without a full two-phase joint entry in the general sense. KRaft still models the transition as a controlled configuration change committed through the log (`VotersRecord`), and conceptually relies on the same joint-overlap safety property. The practical upshot for operators: **you may only change membership by one voter at a time**, which is why a 3→5 grow is two separate add-controller operations. ## Worked example: why two-at-once is unsafe Suppose `C_old = {1,2,3}` (majority 2) and you tried to jump directly to `C_new = {3,4,5}` (majority 2). Nodes {1,2} could form a majority of `C_old` and elect leader A; nodes {4,5} could form a majority of `C_new` and elect leader B — disjoint, two leaders. Single-server steps (`{1,2,3}` → `{1,2,3,4}` → `{1,2,3,4,5}` → ...) make every adjacent pair of configurations overlap, eliminating that gap. ## Edge cases and operational notes - A configuration change entry takes effect **as soon as a replica appends it**, not when it commits — so even an uncommitted change must be handled safely (KRaft accounts for this). - If a membership change is in flight and the leader crashes, the new leader continues or aborts the transition based on what is in its log; the single-server constraint keeps this safe. - Removing the current leader from the voter set is handled by stepping down after the change commits. - This is purely about the **controller voter set**, not broker membership, which is tracked separately as registrations. ## Takeaway Joint consensus / single-server changes guarantee that during any membership transition there is never a moment when two disjoint majorities can act independently — that overlap property is the whole point, and it is why KRaft forces one-voter-at-a-time reconfiguration.