Suppose a network partition isolates the current Raft leader from the rest of the cluster, but that leader doesn't crash - it just can't reach anyone. The majority side elects a new leader. When the partition heals, how does the protocol prevent both leaders from being treated as valid, and what stops the old leader from having accepted writes in the meantime?

## The two cooperating mechanisms Raft prevents split-brain using two cooperating mechanisms: 1. a strictly increasing **term** number, and 2. the **majority-quorum requirement** for every consequential action (both winning an election and committing a log entry). Neither mechanism alone is sufficient - it's their combination that closes the gap. ## Terms as a logical clock Every node tracks a `currentTerm`, starting at 0 and incrementing every time an election is called. A term acts like a logical clock: within a single term there can be at most one leader, guaranteed because a candidate needs a majority of votes to win, and Raft's voting rule says a node casts at most one vote per term, so two different candidates can't both collect a majority in the same term - their vote sets would have to overlap, and an overlapping voter can't vote twice. When a partition isolates the current leader from the majority, the followers on the majority side each start their own randomized election timeout (since they stop receiving heartbeats), and one of them - say node B - times out first, increments its term from, say, 5 to 6, and requests votes. Because the old leader (still on term 5) is unreachable to vote and everyone else on the majority side is also on term 5 and hasn't voted yet in term 6, node B collects a majority of the reachable nodes and becomes leader for term 6. ## What the isolated leader can and cannot do Meanwhile, the old leader (still calling itself leader on term 5) is completely unaware of this. - It keeps sending heartbeats and `AppendEntries` into the void, and if it receives client writes, it appends them locally as uncommitted entries. - Crucially, it can never mark them committed, because committing requires a majority of `AppendEntries` acknowledgments, and it can't reach the followers who form that majority. - So from the client's point of view, assuming the client waits for a commit acknowledgment as it should, those writes never succeed - they just hang or eventually time out. This is the second half of the mechanism: term numbers prevent two leaders from ever winning the same election, and the quorum requirement independently prevents the stale leader from making its writes durable even while it's mistakenly still acting as leader. ## When the partition heals When the partition heals, the reconciliation is almost mechanical. Raft's rule is simple and applied uniformly to every RPC: whenever a node - leader, candidate, or follower - sees a term number higher than its own `currentTerm` in any incoming request or response, it immediately updates `currentTerm` to that higher value and reverts to follower state, abandoning any leader or candidate role it held. So the moment the old leader (term 5) either sends a heartbeat to node B (now term 6, and B's response carries term 6) or receives a `RequestVote/AppendEntries` from B, it sees term 6 > its own term 5, steps down, and becomes a follower of B. Its uncommitted log entries from the partition window get resolved by the standard log-matching-and-backtrack process - B's log wins for any conflicting positions, and the old leader's uncommitted entries are discarded, exactly as if they had never happened, which is safe because they were never acknowledged to clients as committed. ## Why detection is sidestepped The reason this design exists is that a network partition, from any single node's local point of view, is indistinguishable from the rest of the cluster being slow, offline, or crashed - there's no reliable way for the isolated leader to detect 'I've been partitioned' versus 'everyone else happens to be busy.' Rather than trying to detect partitions (which is provably impossible in general), Raft sidesteps the detection problem entirely: - it makes staleness self-correcting via term comparison, and - it makes premature commitment structurally impossible via the quorum requirement, so a stale leader is harmless by construction rather than by any explicit check. ## The trade-off and the operational trap The trade-off is the liveness cost already discussed - the isolated leader is wasted for the duration of the partition, unable to do useful work even though it's fully healthy, and clients talking to it experience hung requests rather than fast failures unless they have their own timeout logic. In production, this shows up as a subtle operational trap: monitoring that only checks whether the leader process is up and responding to heartbeats can show green while writes are actually failing, because the leader is up but not committing - which is why healthy Raft-based systems (etcd, Consul) expose commit-index / quorum-health metrics separately from basic liveness checks, and clients are expected to implement request timeouts with leader-redirect retries rather than trusting a single node indefinitely.