Common Interview and Exam Questions

Questions you should be able to answer aloud

1. Why does a consensus cluster need a majority, and why use odd sizes? Majorities intersect; an even size adds cost without tolerating more failures. 2. Walk through a Raft leader election and a split vote. Timeout, term increment, self-vote, RequestVote, majority wins, randomised timeouts break ties. 3. How does Raft guarantee a new leader has all committed entries? Election restriction plus majority overlap. 4. Why can a leader not commit an old-term entry by counting replicas? The Figure 8 scenario; commit a current-term entry instead. 5. Paxos vs Raft? Same quorum logic; Raft fixes leader election, log structure and membership details. 6. What is FLP and how do real systems live with it? Safety always, liveness under partial synchrony. 7. 2PC vs consensus? All participants vs a majority; 2PC blocks on coordinator failure. 8. How would you build a distributed lock? Lease in etcd or ZooKeeper plus fencing tokens checked by the resource.

Structure beats memorisation

For any 'design with consensus' question, cover four points in order: what is replicated (the log), who decides order (the leader), what makes it safe (majority overlap plus the voting rule), and what happens on failure (election, catch-up, fencing). Draw the cluster before you talk.

Explaining Raft like cricket captaincy

The team (cluster) has one captain (leader) per match (term). If the captain is unreachable for too long, a player volunteers (candidate) and needs most of the team's support; players back only someone who has followed the match at least as closely as they have. Decisions recorded in the scorebook by a majority are never erased.

Quick check: An interviewer asks why a 4-node Raft cluster is rarely used. What is the best answer?

• Raft does not support even-sized clusters
• Four nodes cannot elect a leader
• It tolerates the same single failure as 3 nodes while needing 3 acknowledgements per commit
• Four nodes always cause split brain