Distributed Consensus in 15 Minutes!
summary
Clear, implementable claim: Raft ties append-only logs across servers so a leader proposes entries and a majority commit makes them immutable; a minority may lag but cannot alter committed state. Demonstrated tooling: Raft plus a causal barrier implemented as bookmarks (transaction IDs) delays a read at a replica until replication finishes, avoiding “account created then not found” glitches. Proven practical at scale (teams of ~20 engineers) and works over WAN with that simple extension.
AI-written summary · about
chapters (10)
- 0:00Introduction and welcome
- 1:01Personal story and consensus basics
- 2:48Why consensus is hard
- 3:51Introducing Raft protocol
- 5:35Raft’s log replication
- 7:19Eventual consistency pitfalls
- 8:22FLP impossibility result
- 9:26Strong consistency with Raft
- 10:29Causal boundaries and bookmarks
- 12:17Takeaways and recommendations
related talks
47mDistributed Systems: When Democracy and Computer Science Come Together
41mThe Raft Consensus Algorithm
47mUnderstanding Raft Consensus
01h 32mHow to Reach Consensus with Paper, Pencil and the Raft Algorithm
44mCluster Consensus: When Aeron Met Raft
01h 27mHow to Reach Consensus Using Paper, Pencil and the Raft Algorithm
12mFault-Tolerant Replication with Pull-Based Consensus in MongoDB
51mDo Not Reimplement Distributed Consensus Algorithms