The interview question. Five nodes run a Raft-backed configuration service. A, B, C, D and E normally communicate. A is leader. A network failure separates A and B from C, D and E. A still has a healthy disk, valid credentials and clients that can reach it. What may A safely do? How can the three-node side recover service? Explain elections, terms, voting rules, and the difference between serving a stale read and accepting a new write.
Assume fixed voting membership, crash-fault Raft rather than Byzantine faults, and durable term, vote and log state. This question is about who is authorized to decide. Whether an asynchronous replica contains an acknowledged transaction after failover is a separate durability question.
Think first
Five voters A, B, C, D, E split into A+B and C+D+E. A was the leader in term 11 and still receives writes from clients. C is elected in term 12. What may each partition safely acknowledge, how do candidates qualify for election, and how would you test what happens when A rejoins?
Take a few minutes to form an approach, then compare it with the worked explanation.
Reveal the worked explanation
A server can feel healthy while losing authority
A receives client traffic. Its health endpoint returns 200. It has not observed an explicit resignation. It might even keep sending heartbeats to B. None of that tells A whether C, D and E have elected someone else.
From A's viewpoint, those three machines might have crashed, might be delayed, or might be communicating perfectly without A. A timeout cannot distinguish those histories. So Raft does not let a leader commit a new log entry merely because it considers itself alive.
With five voters, committing an entry under ordinary Raft rules needs a majority of three. A and B make only two. A can append a proposed command locally, but it cannot commit it as a new durable decision or honestly return a successful linearizable write based solely on those two copies.
Five Raft voters split into a minority with the old leader and a majority that can elect a new leader
The C, D and E side has enough voters to make progress. After election timeouts, one may start an election, increment the term, and request votes. A candidate must have a sufficiently up-to-date log, judged by the last entry's term and then index, and must win a majority for that term. It is not safe to elect whichever machine responds first. Election restrictions help ensure a successful candidate preserves already committed entries.
What changes when C becomes leader?
Suppose C wins three votes in term 12. Its election does not require A's consent because any two majorities of the same fixed five-node configuration overlap. There cannot be two disjoint sets of three voters that both elect different leaders for the same term under the voting rules.
A may still believe it is leader in term 11 while the partition continues. This is uncomfortable but not, by itself, a violated consensus safety property. A cannot commit new entries with only B. C can coordinate new commits with D and E. Once A receives a valid Raft message bearing term 12, it updates its term and stops acting as term-11 leader.
Terms fence Raft protocol messages. An old-term AppendEntries request must not overwrite a newer-term leader's decisions. Persistent voting state, log matching, and commit rules make this stronger than an application-level boolean named isLeader.
The minority may expose clearly labeled stale or diagnostic reads if the product contract permits them. It must not present its local state as an up-to-date linearizable read without establishing current authority through a safe read protocol. A local value can be well formed and fully applied while missing decisions made by C after the partition.
What can the client observe?
Client X sends a configuration update to A and gets a timeout. That timeout leaves the operation unresolved, not necessarily rejected. The command might have remained uncommitted locally. After A rejoins, the new leader can overwrite a conflicting uncommitted suffix. X should use a stable operation identity where repeating the business command could matter, and retry through the current authority.
Client Y reaches C after its election and writes successfully. That requires a committed log entry under the configured durability rules and a state-machine result if the API promises one. The response must not be based solely on election success.
If the partition heals, A does not simply broadcast its old local log as the winner. It accepts a valid leader in a higher term, finds the matching log prefix, and reconciles its uncommitted suffix according to Raft replication. Already committed entries have stronger protection than arbitrary local proposals.
Some deployments use leader checks that proactively step down when quorum is lost. That improves how quickly a stranded A refuses work, but it is an implementation and availability choice. The fundamental safety guarantee cannot depend on detecting the partition within an exact number of milliseconds.
When the majority side cannot make progress either
Three nodes being reachable does not automatically imply they are ready to serve successful writes. If their disks are unhealthy, the candidate cannot obtain enough votes, or new log entries cannot be persisted, the system may remain unavailable. Majority size is necessary for progress under this model, not a guarantee of healthy hardware or low latency.
And quorum arithmetic must use the configured voters, not whichever processes happen to be running. An operator must not declare A and B "removed" by editing a local environment variable so the minority can elect itself. Membership change is another consensus decision, which we will address later in this series.
The strongest interview response begins with this distinction: a healthy machine is not necessarily an authorized writer. Name the voter set, the majority threshold, the election restrictions, and the read guarantee before proposing failover automation.
Now consider a different puzzle. A new leader has already won the election. It discovers an older log entry present on three of five servers. Is that enough to call the entry committed?
Go deeper
Why random election timeouts matter
If several followers start elections simultaneously, they can split votes and fail to choose a leader. Randomized election timeouts reduce repeated collisions. They are a liveness technique, not the argument that makes two leaders unable to commit incompatible decisions.
A majority is not a lock on an external system
The Raft term controls Raft decisions. If a worker elected by a Raft-based coordinator can still write to an unrelated database after losing its lease, that database may need its own enforcement against obsolete workers. Part 3 of 5 handles that separate boundary.
Check the history, not the health endpoint
A good test partitions the old leader away from three peers, verifies minority writes do not succeed, verifies the healthy majority can elect and commit, and checks that rejoining A cannot resurrect an uncommitted suffix. Read tests should distinguish stale diagnostic access from linearizable API promises.
Check your reasoning
Use three of five configured voters as the quorum threshold, not whichever nodes are reachable.
Show why A+B cannot commit new Raft log entries although A may still believe it leads.
Explain randomized elections, persistent terms and votes, and voting for an up-to-date log.
Separate stale diagnostic reads from linearizable reads that need current authority.
Address unresolved client writes and reconciliation of an uncommitted old-leader suffix.
Common mistake: Treating a process that still serves traffic as an authorized leader, or assuming a heartbeat alone proves current leadership.
Read the answer explanation
No, it cannot commit a new entry without the configured majority. — The original five-voter membership still governs. Two votes cannot authorize a new commit.
Apply it elsewhere
A Kubernetes-style controller has a leader flag cached in memory while its backing lease service is unreachable. Should it continue writing external resources?
Compare your approach
Its authority must be re-established or protected by a destination-side mechanism. A local leader flag cannot confer permanent write authority.
One more constraint
Can the old leader serve locally consistent but stale reads while lacking quorum? What must the API label?
Quick revision
A Raft leader requires a majority of the configured voting group, not just the nodes it can reach. In a five-node 2–3 partition, the old leader on the two-node side may remain alive but cannot commit new writes. The other three nodes can elect a leader using persistent terms, one vote per term, and candidate log-freshness rules. The old leader must step down when it observes the higher term, and an uncommitted suffix may be overwritten on rejoin. Strong reads also require a safe current-authority protocol. Do not mistake local process health for write authority.
