Distributed Consensus Interview Questions: Raft, Paxos, Quorums, and Split Brain

During a network partition, two servers can both look healthy and both believe the other side failed. The hard part is not choosing a leader quickly; it is proving that only one side can make a decision the system will never reverse.

This guide covers distributed consensus interview questions about Raft, Paxos, quorums, and split brain. The answers focus on the invariants behind the algorithms, then connect them to elections, replicated logs, linearizable reads, membership changes, and real operational failures.

Use PracHub to practice real interview questions with written solutions, then narrow your preparation with company-specific interview prep. Start with the safety property, trace the quorum, and make every failure transition explicit.

A senior consensus answer proves why one decision survives elections, message delays, and network partitions.

Quick Verdict: What a Senior Consensus Answer Includes

A strong answer does not stop at "use Raft." It defines what must never happen, which nodes may decide, how the decision becomes durable, and how stale authority is rejected.

Consensus Fundamentals Interview Questions

1. What problem does distributed consensus solve?

Consensus lets multiple non-Byzantine nodes choose one value even when messages are delayed, duplicated, lost, or reordered and some nodes crash. In a replicated state machine, that value is usually the next command in an ordered log.

Every deterministic replica applies the same committed commands in the same order, so they reach the same state. Consensus protects the decision history; it does not automatically provide business-level idempotency, backups, or protection from malicious nodes.

2. What is the difference between safety and liveness?

Safety means nothing bad happens: two different values are not chosen for the same log position, and committed history is not replaced. Liveness means something good eventually happens: the cluster eventually chooses a value and clients make progress.

Raft and Paxos preserve safety without relying on accurate clocks. Timeouts and randomness help liveness by ending indecision, but a severe partition or perpetual leadership conflict can stop progress without making the protocol choose two values.

3. How are consensus, replication, and leader election different?

Replication copies data. Leader election chooses a temporary authority. Consensus proves that a decision, such as a leader term or log entry, is compatible with every decision that can be made later.

A health-check election without quorum history is not consensus. Two partitions can each elect a local leader unless voting rules, persistent terms or ballots, and log eligibility force every valid authority to intersect prior decisions.

4. Why do consensus protocols commonly use a majority quorum?

Any two majorities of the same fixed membership intersect in at least one node. That overlapping node carries information about an earlier accepted or committed decision into the quorum used by a later proposer or leader.

With 2f + 1 voting nodes, a majority can tolerate up to f crash failures: three nodes tolerate one and five tolerate two. Adding an even-numbered voter usually increases cost without increasing the number of failures the cluster can survive.

5. Do Raft and Paxos tolerate Byzantine failures?

Classic Raft and Paxos assume crash or crash-recovery failures, not arbitrary malicious behavior. Messages may be delayed or lost, and nodes may stop and restart, but a node is not expected to forge votes or deliberately violate the protocol.

Byzantine fault tolerance requires stronger protocols and typically larger quorums. In an interview, state the failure model before giving a replica count; otherwise the formula has no defensible meaning.

Raft Interview Questions

6. What are Raft terms and server roles?

A Raft server is a follower, candidate, or leader. Time is divided into monotonically increasing terms, and a term begins with an election; at most one leader can win a given term.

Terms act as a logical authority clock. A node that receives an RPC carrying a higher term updates its term and becomes a follower, which prevents an old leader from remaining authoritative inside the Raft group.

7. How does Raft elect a leader safely?

A follower starts an election after its randomized timeout, increments its term, votes for itself, and requests votes. A candidate needs a majority of the full voting configuration and each voter grants at most one vote per term.

Votes also enforce log freshness. A voter rejects a candidate whose last log term is older, or whose log is shorter when the last terms match. This election restriction prevents a candidate missing committed entries from becoming leader.

8. How does AppendEntries keep logs consistent?

The leader sends each follower the previous log index and term along with new entries. The follower accepts the append only if its log matches at that boundary; otherwise the leader backs up and retries until it finds the shared prefix.

After that point, conflicting follower entries are removed and replaced with the leader's entries. A leader never overwrites its own log, and an uncommitted entry may disappear after leadership changes.

9. When is a Raft log entry committed?

A leader can commit an entry from its current term after that entry is stored on a majority. Committing it also commits all preceding entries in the leader's log through the Log Matching property.

The subtle rule is that an older-term entry cannot be declared committed merely because a new leader counts it on a majority. It becomes committed indirectly after the leader commits a current-term entry; otherwise a future leader could still overwrite that older entry.

10. What happens to an isolated old Raft leader?

It may continue believing it is leader until it observes a higher term, but it cannot commit new entries without a majority. The majority partition can elect a new leader and continue safely while the minority stops making authoritative decisions.

When communication returns, the old leader sees the higher term and steps down. Its uncommitted suffix is repaired to match the current leader, but any external side effect it issued still requires a fencing strategy outside Raft.

11. How does Raft provide linearizable reads and safe retries?

A leader must confirm that it still holds authority before serving a linearizable read, commonly by communicating with a quorum or using a carefully bounded leader lease. Reading local state from an isolated former leader can return stale data.

A committed command can execute even when the client times out before receiving the response. Clients therefore attach unique request IDs, and the replicated state machine stores enough result history to make retries return the original result instead of applying the command twice.

12. How does Raft change membership and compact its log safely?

Switching every node directly from an old configuration to a new one is unsafe because the two configurations can temporarily form independent majorities. Raft's joint consensus phase requires separate majorities from both configurations before moving fully to the new set.

New nodes should first catch up as non-voting learners so they do not enlarge quorum before they are useful. Snapshots compact committed state while preserving the last included index, term, and current configuration; a follower that falls behind the retained log installs a snapshot.

Paxos Interview Questions

13. What are proposers, acceptors, and learners in Paxos?

A proposer attempts to get a value chosen, acceptors persist promises and accepted proposals, and learners discover which value a majority accepted. One process may perform several roles.

The key safety fact is not that one proposer exists. Basic Paxos can remain safe with competing proposers because acceptors enforce proposal-number rules; a distinguished proposer mainly improves progress.

14. What happens in Paxos Phase 1?

A proposer chooses a unique, increasing proposal number and sends Prepare to acceptors. An acceptor responding to a higher-numbered prepare promises not to accept proposals with lower numbers and returns its highest-numbered accepted proposal, if any.

The promise closes the door on lower-numbered proposals. The returned accepted value tells the new proposer whether an earlier decision may already be forming and therefore constrains what it may propose next.

15. What happens in Paxos Phase 2?

After receiving Phase 1 responses from a majority, the proposer sends an Accept request. If any response reported an accepted proposal, the proposer must use the value from the highest-numbered one; otherwise it may use its own proposed value.

An acceptor accepts the request unless it has already promised a higher proposal number. A value is chosen when one proposal carrying that value has been accepted by a majority, even if no learner has heard the result yet.

16. Why must a proposer preserve the highest-numbered accepted value?

A previous value may already have been chosen by a majority the new proposer cannot see in full. Because the new Phase 1 majority intersects every earlier decision majority, at least one response carries evidence of that value.

Selecting the highest-numbered accepted proposal preserves the invariant that every later chosen proposal has the same value. Choosing a fresh value despite that evidence can violate safety.

17. Why is Paxos safe with lost, duplicated, or reordered messages?

Proposal numbers make old messages recognizable, and acceptors persist both their highest promise and highest accepted proposal before responding. A delayed lower-numbered Accept cannot pass an acceptor that has promised a higher number.

Messages may be retried without changing the decision rule. Safety depends on durable acceptor state and quorum intersection, not arrival order or a perfect network.

18. Why can Paxos stop making progress, and what does Multi-Paxos change?

Two proposers can repeatedly preempt each other with increasing proposal numbers, so neither completes Phase 2. Electing a distinguished proposer stabilizes leadership and restores progress when it can reach a majority.

Multi-Paxos uses that stable leader across many log positions. After leadership is established, the leader can usually skip a fresh prepare round for every command and drive the accept phase directly, while leader changes re-establish ballot authority.

Raft, Paxos, Quorums, and Split Brain

19. How should you compare Raft and Paxos in an interview?

Both use intersecting quorums and ordered authority numbers to preserve one decision under crash failures and partitions. Paxos expresses safety through proposals, promises, acceptances, and learners; Raft builds a strongly leader-oriented replicated log around terms, elections, and AppendEntries.

Do not reduce the answer to "Raft is easier." Explain the operational consequence: Raft specifies leader eligibility, log repair, commitment, reconfiguration, snapshots, and client interaction as one coherent protocol, while production Multi-Paxos systems must make those implementation choices explicitly.

20. How do consensus systems prevent split brain during a network partition?

Only a partition containing a valid quorum can elect authority and commit new decisions. A minority may remain responsive or even contain the old leader, but it must reject authoritative writes or serve only explicitly stale reads.

Consensus protects state inside the replicated log. For databases, file systems, or job runners outside that log, attach a monotonically increasing term, ballot, or fencing token and make the destination reject older tokens. A lease or process shutdown alone cannot stop a delayed request from the former leader.

Raft and Paxos use different vocabulary, but both preserve decisions by carrying prior authority through intersecting quorums.

Worked Scenario: A Five-Node Configuration Service Splits 3-2

Suppose a five-node Raft cluster stores service configuration across three availability zones. A network failure divides it into groups of three and two, with the old leader trapped in the two-node side.

The three-node partition can elect a candidate only if its log is sufficiently up to date. It commits a new configuration after replicating a current-term entry to its majority. The old leader cannot commit because it reaches only two voters, even if it still accepts client connections.

Clients retry timed-out writes with stable request IDs. Every update sent to downstream workers carries the current leadership term as a fencing token, so workers reject a delayed command from the old leader.

When the partition heals, the old leader observes the higher term, steps down, and repairs its uncommitted log suffix. If an operator replaces a node, the replacement catches up as a learner before a joint-consensus membership change alters the voting set.

What Interviewers Are Actually Scoring

Junior answers define leader and majority. Mid-level answers trace an election and log commit. Senior answers state the failure model, prove quorum intersection, separate safety from liveness, explain ambiguous retries, and fence external side effects.

Interviewers listen for precise words: accepted is not necessarily chosen, replicated is not necessarily committed, elected is not necessarily safe to serve stale local reads, and losing quorum should stop new decisions rather than create a second truth.

Use PracHub's system design questions to practice these transitions aloud. Distributed-systems loops also test incident judgment and stakeholder communication, so include behavioral and leadership practice in your final preparation.

A Five-Step Framework for Any Consensus Question

1. Name the decision. Define the value or log position that all replicas must agree on.

2. State the failure model. Specify crash failures, message behavior, persistence, and the number of faults to tolerate.

3. Prove authority. Show the term or ballot and why every valid decision quorum intersects the next authority quorum.

4. Trace commitment. Separate proposed, accepted, replicated, committed, learned, and applied states.

5. Walk the failure. Cover partitions, quorum loss, retries, stale leaders, fencing, log repair, and membership change.

Frequently Asked Questions

Is Raft always better than Paxos?

No. Raft offers a cohesive, strongly leader-based specification that is often easier to explain and operate. Paxos is a family of consensus techniques with many production variants and optimizations. The better choice depends on the implementation, proof, operational tooling, and workload.

Does consensus guarantee exactly-once execution?

No. A command can commit before the client receives the response, causing a retry after failover. Exactly-once business effects require stable request IDs, deduplication state inside the replicated state machine, and idempotent handling of external side effects.

Why are consensus clusters usually an odd size?

An odd number uses replicas efficiently for majority fault tolerance. Three voters need two for quorum and four need three, so both tolerate only one voter failure for progress; the fourth voter adds quorum cost without increasing tolerated failures.

Can two Raft leaders exist at the same time?

They can exist in different terms, and an isolated old leader may not yet know it has been replaced. Raft guarantees at most one elected leader per term; only the leader that can reach a current quorum can commit new entries.

Is a consensus quorum the same as W + R > N?

No. Both use intersection, but Dynamo-style read/write quorums and consensus voting quorums enforce different protocols. Consensus also carries ordered authority and accepted-history rules so later decisions cannot contradict an earlier chosen value.

Final Takeaway

The best distributed consensus interview answers prove an invariant rather than recite an algorithm. Explain how a value becomes chosen, why a later leader must preserve it, what stops during quorum loss, and how stale authority is fenced outside the log.

Practice that reasoning against realistic prompts in PracHub's interview question library. Repeat each failure path until you can distinguish election, acceptance, commitment, application, and external effects without collapsing them into "the majority agreed."

Official Sources

In Search of an Understandable Consensus Algorithm defines Raft's terms, election restriction, log matching, current-term commit rule, joint consensus, snapshots, and client retry handling.

Paxos Made Simple defines proposers, acceptors, learners, majority intersection, Prepare and Accept phases, durable promises, and the distinguished proposer used for progress.

The etcd API guarantees illustrate linearizable versus potentially stale reads in a Raft-backed production system. Google's Chubby paper documents lock-generation sequencers that let downstream services reject delayed requests from stale lock holders.