Raft lecture (Raft user study)
Why Hacker News recommends it
HN commenters recommend it as a clearer introduction to Raft than the paper and as part of a well-designed understandability study.
What it is
John Ousterhout lectures on the Raft consensus algorithm, made for the Raft user study comparing how students learn Raft and Paxos. It covers leader election and log repair.
Recommended by 4 HN commenters across 4 different months, 2013 to 2025.
What Hacker News said
Strong rec krat0sprakhar · 2014-10 · on “The Raft Consensus Algorithm”
One of the most lucid explanations of the Raft Consensus Algorithm that I've ever seen is the one in John Ousterhout and Diego Ongaro's Raft User Study[0]. The 2 videos do an excellent job of explaining both the Paxos and Raft algorithms and the key differences between them. John's narration is extremely clear and the slides are very informative. Definitely recommended! Raft is a consensus algorithm designed to be easier to understand than Paxos. To measure Raft's understandability, we conducted an experimental study using CS students at two universities. We recorded a video lecture of Raft and another of Paxos, and created corresponding quizzes. This page makes our materials available for a
Recommends tomjohnson3 · 2013-09 · on “ZooKeeper vs. Doozer vs. Etcd”
one other thing to keep in mind is that the underlying algorithms (zab and raft) provide different guarantees. for example, zookeeper/zab allows reading directly from followers with a guarantee to get at least a past value that won't be rolled back. this was one reason zookeer didn't use paxos: [LINK] in my understanding, raft doesn't allow reading directly from followers, because the follower logs may get repaired/rolled-back when a new leader is elected. (though i'm sure an implementation can tweak the protocol to provide this support.) that said, raft has a lot of interesting applications, and, in my opinion, is definitely more understandable than the many versions of paxos. (implementing
Recommends pkj · 2013-11 · on “The Writings of Leslie Lamport”
A really good intro to Raft --> [this video] Very useful if you are into distributed systems and would like to see a practical implementation with clear examples.
Recommends sathish316 · 2025-08 · on “The Raft Consensus Algorithm (2015)”
This YouTube video by the Raft creators (linked at the bottom of the page) gives a solid explanation of Raft internals - [this video]
Cites tomjohnson3 · 2013-09 · on “ZooKeeper vs. Doozer vs. Etcd”
i don't think this is the case. here is a link to a video by one of the authors about log repair during leader election: [this video] log entries on a follower may get rolled back - and thrown out - since they were not accepted on a majority of followers.
Cites deathanatos · 2014-09 · on “Raft: Understandable Distributed Consensus”
> and does not address the situation of two nodes having conflicting sets of data (for instance from network partition). I believe it does address this. Each log entry is either committed or not; an entry can only be committed if it has been replicated to a majority of nodes. Any node that lacks a committed entry cannot be elected master because of the election rules: a node will not vote for another node less complete than itself. Since a committed entry has been replicated to a majority, a node lacking that entry cannot receive a majority of the votes. (Thus the committed log entries will always be the same on all nodes (though some may be behind, and may only have a subset), which is the
Cites nieksand · 2014-09 · on “Ask HN: Final year project in CS”
Consider doing some language processing using the excellent NLTK library: [LINK] It wasn't on the lists of "wants", but implementing the Raft consensus protocol could be neat too. It was designed to be understandable and implementable. The video is here: [this video] . The research paper is here: [LINK]
Cites throwawaybbq1 · 2021-04 · on ““They introduce kernel bugs on purpose””
This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities). [edit: specifying the population of a study is pretty important. Getting random students from the University to approve your security patch doesn't make sense. Picking students who successfully completed a computer security course and got a high grade is better than that but again, may not generalize to the real world. One of the most impressive ways I have seen this being done by grad students was a use