Interview Prep Zoneby CuriouserLabs

Question 2 of 5 · senior level

Explain Raft — leader election and log replication — as if to a colleague who knows databases but not consensus.

🎤 Say this first

Raft splits consensus into two understandable halves. Leader election: time is divided into numbered terms; every follower runs a randomized election timeout, and on expiry it becomes a candidate, increments the term and requests votes. A node votes once per term, so only a candidate with a majority wins — that's why two leaders in the same term are impossible. Log replication: all client writes go to the leader, which appends to its log and sends AppendEntries to followers; once a majority has persisted an entry, the leader marks it committed and applies it to the state machine. Followers whose logs diverge get overwritten by the leader's — the leader's log is the truth. The safety trick is the election restriction: a node won't vote for a candidate whose log is behind its own, guaranteeing every new leader already holds all committed entries.

The full picture

🎬 Raft: leader election and log replication

1 / 5
term 4one leader, two followersN1leader · log 1-3N2follower · log 1-3N3follower · log 1-3heartbeatheartbeat3 nodes tolerate 1 failure. So do 4 — which is why cluster sizes are odd.

Term 4: N1 is leader. It sends AppendEntries heartbeats to N2 and N3 to keep them followers — a follower that keeps hearing from a leader never starts an election.

A leader dies, a term increments, a majority votes — and the new leader replicates its log.
MechanismWhat it prevents
One vote per node per termtwo leaders in the same term (split-brain)
Randomized election timeoutsendless split votes — someone times out first
Majority for both vote and commitany two quorums overlap, so history can't fork
Election restriction (log must be up to date)a stale node becoming leader and erasing committed entries
Commit only entries from the current termthe subtle 'committed then overwritten' bug in naive designs
  • The majority-overlap argument is the heart of it — say it explicitly: any two majorities of the same cluster share at least one node, and that node's vote or log entry is what stitches history together across terms. Every quorum system rests on this one set-theory fact.
  • Why odd cluster sizes: 3 nodes tolerate 1 failure, 4 nodes also tolerate only 1 (majority of 4 is 3) — the fourth node adds cost and latency with zero fault tolerance. 5 tolerates 2. This is the single most practical thing to know about running etcd/ZooKeeper.
  • Committed ≠ applied ≠ visible: an entry is committed once a majority has it durably; the leader then applies it and answers the client. A follower may apply later, which is exactly why a read from a follower can be stale unless you do a ReadIndex or lease-based read.
  • Raft vs the reality of throughput: every write costs one disk fsync on a majority plus a round-trip — consensus clusters are for metadata (leader identity, configuration, locks, small state), not for your main data path. Putting a high-volume workload in ZooKeeper is a classic architecture smell.
  • Where you already use it: etcd (so: all of Kubernetes' state), Consul, CockroachDB per-range, TiKV, Kafka's KRaft controller, MongoDB's replica-set elections (Raft-like). Naming two of these grounds the answer immediately.

🔄 Likely follow-up questions

  • Why must a leader be prevented from committing entries from previous terms directly?
  • How does Raft change cluster membership without risking two disjoint majorities?
  • What is a ReadIndex read, and why is it cheaper than replicating a no-op entry?