Paxos Interview Questions and Answers (2026)

Paxos shows up in many distributed‑systems interviews because it captures the essence of consensus without getting lost in implementation details. You’ll often hear a basic question, then a deeper follow‑up that tests whether you can reason about edge cases and performance. Below are the most common prompts, a short spoken answer you can deliver in 45‑90 seconds, and the next question the interviewer typically asks.

1. What problem does Paxos solve?

Paxos is a protocol for achieving consensus among a set of unreliable nodes. It guarantees that all non‑failed nodes agree on a single value even when messages are lost, duplicated, or reordered. In practice, this lets a replicated state machine stay consistent despite crashes or network partitions.

Typical follow‑up: Why can’t we just use a leader election algorithm like Raft instead?

---

2. Who are the three roles in Paxos and what does each do?

• Proposer: Suggests a value to be chosen. It first asks for a proposal number (the prepare phase) and then, if it gets a majority of promises, sends the value in the accept phase.
• Acceptor: Holds the authority to vote. It promises not to accept lower‑numbered proposals after a prepare and may later accept a accept request.
• Learner: Learns the chosen value once a majority of acceptors have accepted it. In many deployments learners are also the nodes that apply the value to their state machine.

Typical follow‑up: What guarantees that only one value gets chosen?

---

3. Walk through the two phases of single‑decree Paxos.

1. Prepare phase: A proposer picks a unique, monotonically increasing number n and sends a prepare(n) to all acceptors. Each acceptor replies with a promise not to accept proposals numbered less than n and, if it has already accepted a value, includes the highest-numbered accepted value.
2. Accept phase: If the proposer receives promises from a majority, it selects the highest-numbered value it learned (or its own if none) and sends accept(n, v) to the acceptors. Acceptors that have promised n will accept v and record it. When a majority of acceptors have recorded the same value, learners can safely consider it chosen.

Typical follow‑up: How does the protocol avoid “split‑brain” where two values appear to be chosen?

---

4. Explain why Paxos is safe but not always live.

Safety means that once a value is chosen, no other value can ever be chosen. This holds because any later proposer must include the highest-numbered accepted value in its accept request, forcing convergence on a single value. Liveness (eventual progress) can be blocked if proposers keep generating higher numbers without ever completing the accept phase—think of a storm of competing leaders. Adding a stable leader (as in Multi‑Paxos) or using exponential back‑off helps restore liveness.

Typical follow‑up: What practical mechanisms do systems use to improve liveness?

---

5. What is Multi‑Paxos and how does it differ from basic Paxos?

Multi‑Paxos extends the single‑decree protocol to a sequence of commands (a log). After the first value is chosen, one node becomes a leader and skips the prepare phase for subsequent entries, sending only accept messages. This reduces round‑trip latency from two network delays per entry to one. If the leader fails, a new leader must run the full two‑phase handshake to re‑establish authority.

Typical follow‑up: What are the trade‑offs of keeping a long‑lived leader?

---

6. How does Paxos handle network partitions?

During a partition, each side may still gather a majority if the partition size permits. If both sides can form a majority, they might each choose different values, violating safety. To prevent this, most deployments require a quorum larger than half of the total nodes (e.g., 3 out of 5). Only the partition that holds the quorum can make progress; the other side stalls until the partition heals.

Typical follow‑up: Can you give an example where a minority partition can cause a temporary loss of availability?

---

7. Compare Paxos to Raft in terms of understandability and performance.

Typical follow‑up: When would you still pick Paxos over Raft?

---

8. What are some real‑world systems that use Paxos or its variants?

• Distributed databases such as Google Spanner (uses a variant called TrueTime‑Paxos) and Apache Cassandra (employs a lightweight Paxos for conditional writes).
• Coordination services like ZooKeeper historically used Zab, a Paxos‑inspired protocol.
• Consensus layers in blockchain platforms sometimes adopt a Paxos‑style quorum. The exact implementation details differ by team, but the core safety property remains the same.

Typical follow‑up: How does the presence of a high‑resolution clock in Spanner affect Paxos?

---

9. Describe a failure scenario where a proposer repeatedly loses the election and how you would mitigate it.

If several proposers keep generating higher numbers, each aborts after the prepare phase because another proposer’s number outranks theirs. The system makes little progress. Mitigation strategies include:

• Leader election with back‑off: After a failed attempt, a proposer waits a random interval before retrying.
• Sticky leader: Once a node becomes leader, other nodes defer new proposals unless the leader crashes.
• Batching: Group multiple client commands into a single proposal to reduce the number of elections. These tactics reduce contention and improve liveness.

Typical follow‑up: What metric would you monitor to detect this contention?

---

10. How would you explain Paxos to a non‑technical stakeholder?

"Imagine a group of people trying to decide on a single movie to watch. Each person can suggest a movie, but they must first promise not to change their mind after hearing a higher‑priority suggestion. Once a majority agrees on one movie, everyone watches that movie, even if some people later suggest different titles. Paxos works the same way for computers: it ensures they all choose the same value, even if some crash or the network glitches."

Typical follow‑up: Why does this matter for our product’s reliability?

---

How to practice this

1. Record yourself answering each question in under a minute. Listen for filler words and tighten the phrasing.
2. Use Call Assistant to simulate a live interview: let it detect the next question and keep the conversation on topic while you stay focused on your resume‑aligned stories.
3. Run a tabletop simulation with a colleague: assign proposer, acceptor, and learner roles, step through the two phases, and discuss what happens when messages are lost.

---

FAQ

• Q: Do I need to know the full formal proof of Paxos safety? A: No. Interviewers expect you to articulate the intuition—majority quorums, monotonic proposal numbers, and the guarantee that any later proposer must adopt the highest accepted value.
• Q: How deep should I go into the mathematics of quorum intersection? A: A brief mention that any two majorities intersect in at least one node is enough; elaborate only if the interviewer probes further.
• Q: What if I’m asked to write pseudo‑code for the acceptor logic? A: Sketch the two handlers—onPrepare(n) returns a promise and the highest accepted pair, onAccept(n, v) stores the pair if the promise holds. Keep it high‑level.
• Q: Should I compare Paxos to consensus algorithms used in blockchains? A: You can note that many blockchain protocols borrow the quorum idea but add economic incentives and probabilistic finality, which differ from Paxos’s deterministic safety.