Chapter 6 · Watch, then practise
Coordination and Agreement
Use Raft to distinguish leader election from preserving committed history. Work with majorities and explicit failure assumptions.
3 questions · 3 with related videos. Matches are based on playlist titles; broader background matches are labeled.
What to study
- Leader election
- Quorum intersection
- Safety and progress
Chapter playlists
Choose a playlist
Notes
Distributed Systems 6.2: Raft
Martin Kleppmann · 38:09
Supplementary Raft lecture covers elections, replication and majority decisions; the cluster example is worked in the answer.
1. Majority calculation
In a fixed five-server Raft cluster, what is a majority and how many unavailable servers can it tolerate?
Three votes form a majority. Two servers may be unavailable if the remaining three communicate. Any two majorities overlap, preventing two candidates from winning the same term when each server votes at most once.
Distributed Systems 6.2: Raft
Martin Kleppmann · 38:09
Supplementary Raft lecture covers elections, replication and majority decisions; the cluster example is worked in the answer.
2. Why elections inspect logs
Why is selecting any reachable server as leader insufficient?
A new leader must preserve committed operations. Raft restricts voting using the candidate’s last log term and index, in addition to term and voting rules. Reachability alone says nothing about whether a candidate holds the necessary history.
Distributed Systems 6.2: Raft
Martin Kleppmann · 38:09
Supplementary Raft lecture covers elections, replication and majority decisions; the cluster example is worked in the answer.
3. A network partition
A five-server cluster splits into groups of three and two. Which side can make progress under Raft’s assumptions?
The group of three can elect a leader and commit new current-term entries if its members communicate successfully. The group of two cannot obtain a majority. Waiting on the minority side protects agreement rather than allowing conflicting commits.