Raft Consensus, Explained With Animations

Five copies of your data protect you from a dead disk, but who decides the next write? Raft answers with one leader per term, elected by a majority. We animate heartbeats and election timeouts, terms and votes, split votes and the randomized timeouts that end them (the paper's numbers: greater than 10 s without randomness, ~287 ms median with 5 ms of it, 35 ms average with short timeouts), log replication and commitment, the election restriction, a network partition with two 'leaders', and why clusters are 3 or 5 nodes, not 4. 0:00 Five copies, one truth 0:46 One leader, many followers 1:18 When the leader dies 2:07 Split votes 3:00 Agreeing on the data 3:47 The network splits 4:47 Why five, not four 5:26 Talking to the cluster 5:54 Keeping the log small 6:30 Changing the cluster 7:08 Where it runs 7:43 The takeaway Sources and further reading: • etcd docs: runtime reconfiguration (one member at a time) • Diego Ongaro & John Ousterhout, "In Search of an Understandable Consensus Algorithm" (USENIX ATC 2014) • etcd FAQ: cluster size and failure tolerance • Apache Kafka 4.0.0 release announcement (KRaft, no ZooKeeper) • raft.github.io Latent — the hidden side of software. Real problems, why the obvious fix fails, and what actually works. #distributedsystems #systemdesign #raft