Questions: View Change and Leader Failover Protocols

Question 1

In a distributed system using a view change protocol, the old leader committed operation C in log slot 7 and received majority acknowledgments — but crashed before broadcasting the commit notice to all replicas. A new leader is elected. What must the new leader do before accepting any new client requests?

• A. Start with an empty log and rebuild state from client re-requests to avoid inheriting potentially corrupt state
• B. Collect log state from a quorum of replicas to reconstruct what was committed (and in-progress) during the previous view, then bring all replicas to a consistent state
• C. Trust its own local log as definitive, since it was elected leader by a majority
• D. Ask each client to re-submit their requests so the new leader can decide which ones to commit

Answer: (B)

The new leader being elected by a majority does NOT mean its log is complete. The old leader could have committed operations that the new leader's replica never heard about — exactly the scenario in this question. By collecting state from a quorum (majority) of replicas, the new leader is guaranteed to find evidence of any committed operation: if C was committed (majority acknowledged it), then at least one member of any quorum saw it. Only after reconstructing committed history and advancing all replicas to match can the new leader safely begin serving new requests without losing committed work.

Question 2

What is 'split-brain' in the context of view change protocols, and why is it the critical safety failure the protocol must prevent?

• A. A situation where two nodes simultaneously believe they are the active leader for the same view, potentially issuing conflicting commands and corrupting the replicated log
• B. A network partition that splits replicas into two groups that cannot communicate with each other
• C. A scenario where the leader's log splits into two conflicting branches during rapid writes
• D. A race condition where two clients submit conflicting commands at the same time

Answer: (A)

Split-brain is the safety violation where multiple nodes believe they are the authoritative leader simultaneously. If both issue commands, the replicated state machine receives different command streams on different replicas, violating the consistency invariant that all non-faulty replicas execute the same sequence of operations in the same order. View numbers prevent this: the protocol ensures at most one node can win leadership for any given view number. When replicas detect a suspected leader failure and initiate a view change, they refuse to acknowledge commands from the old leader's view number, causing it to become a no-op even if it is still running.

Question 3

A replica that holds the longest log among most candidates is typically the safest choice for the new leader, since its log is most up-to-date and no committed operations can be missing.

• T. True
• F. False

Answer: False

Log length alone is an insufficient criterion for leader selection. A long log might contain uncommitted proposals that were never acknowledged by a majority — the former leader could have appended entries optimistically that were never replicated. Conversely, a committed operation might exist on a different replica that has a shorter total log length. View change protocols address this by requiring the new leader to collect and reconcile state from a quorum, not by simply picking the replica with the most entries. Raft's election rules use term numbers and log index together, and Paxos uses ballot numbers to reason about which proposals might have been committed.

Question 4

View numbers in view change protocols are monotonically increasing, meaning the system always transitions to a higher-numbered view and can never revert to a previous leader.

• T. True
• F. False

Answer: True

Monotonically increasing view numbers are essential for preventing split-brain. If a replica receives a message from a leader claiming a lower view number than its current view, it rejects the message — the old leader has been superseded and its commands are invalid. This ensures that once a view change succeeds and replicas have moved to view N+1, the old leader in view N cannot interfere even if it recovers and believes itself still active. The monotonic property is also what allows liveness: if the new leader also fails, view N+2 is triggered, and so on, making progress as long as a majority of nodes are eventually reachable.

Question 5

Why is ensuring the new leader learns all previously committed operations the hardest challenge in a view change, and how does collecting state from a quorum address it?

Model answer: The challenge is that 'committed' is distributed knowledge: an operation is committed when a majority acknowledged it, but no single node may have received the leader's final commit broadcast before it crashed. The new leader therefore cannot determine what was committed just by inspecting its own log. Collecting state from a quorum solves this because any committed operation must have been acknowledged by a majority — and any majority overlaps with any quorum by at least one node. So the new leader's survey of a quorum is guaranteed to include at least one replica that holds evidence of every committed operation, allowing full reconstruction before new work begins.

This question targets the deepest insight about why view changes are where consistency bugs hide. The steady-state leader path is simple — but leader transitions require reasoning about distributed state that no single node fully holds. The quorum intersection property (any two majorities share at least one member) is the mathematical guarantee that makes reconstruction possible and safe.