Build fluency in the vocabulary of a cluster agreeing on a single, replicated log through an elected leader.
0 / 5 completed
1 / 5
At standup, a dev mentions a distributed cluster electing a single node to coordinate all writes for a term, with other nodes replicating that node's log entries. What is this consensus algorithm called?
The Raft consensus algorithm elects a single leader node per term to coordinate all writes, with follower nodes replicating that leader's log entries to stay in sync. Letting every node accept writes independently with no elected leader risks conflicting, unordered writes across the cluster. This leader-based design is what makes Raft's replicated log easier to reason about than a fully leaderless consensus scheme.
2 / 5
During a design review, the team wants a follower node to trigger a new leader election automatically if it stops hearing heartbeats from the current leader within a timeout window. Which capability supports this?
An election timeout makes a follower node trigger a new leader election automatically once it stops hearing heartbeats from the current leader within a bounded window. Waiting indefinitely with no timeout leaves the cluster stuck with no coordinating leader after a real failure. This timeout-driven election is what lets a Raft cluster recover leadership automatically without a person needing to intervene.
3 / 5
In a code review, a dev notices a log entry is only considered committed once it has been replicated to a majority of the cluster's nodes, not just written to the leader's own log. What does this represent?
The majority quorum requirement means a log entry is only committed once it's replicated to more than half the cluster's nodes, not merely written to the leader's own log. Considering an entry committed the instant the leader writes it risks losing that entry if the leader crashes before replicating it anywhere else. This quorum requirement is what gives Raft's committed log its durability guarantee even through a leader failure.
4 / 5
An incident report shows two nodes in the same term both believed they were the cluster's leader and accepted conflicting writes, because the election protocol allowed more than one node to win an election in the same term. What practice would prevent this?
Requiring a candidate to win a strict majority of votes in a term before becoming leader guarantees only one leader can exist per term, since two disjoint majorities can't both exist in the same cluster. Allowing any node with enough votes to declare itself leader, with no strict majority enforced, risks exactly the split-brain scenario this incident describes. This majority-vote rule is the core safety property that keeps Raft's leadership single and unambiguous.
5 / 5
During a PR review, a teammate asks why the team adopts Raft's leader-based replication instead of a leaderless scheme where every node accepts writes independently. What is the reasoning?
A leaderless scheme requires resolving conflicting, concurrently accepted writes across nodes, which adds real complexity to keeping the cluster's state consistent. Raft's single leader per term serializes writes into one agreed-upon, replicated log, avoiding that conflict-resolution problem entirely. The tradeoff is that all writes must pass through the current leader, which can become a throughput bottleneck under very high write volume.