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.
Why Hacker News points people here: HN commenters recommend it as a clearer introduction to Raft than the paper and as part of a well-designed understandability study.
“The 2 videos do an excellent job of explaining both the Paxos and Raft algorithms and the key differences between them.”HN comment, 2014
“The 2 videos do an excellent job of explaining both the Paxos and Raft algorithms and the key differences between them.”
Clear lecture explaining Raft and Paxos and how they differ.
Full comment
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 anyone interested. We think these are valuable resources for anyone learning consensus (whether Raft or Paxos or both). [0] - link Raft Video - this video Paxos Video - link
Recommendstomjohnson3Sep 2013
“i found the videos from the raft user study to be very well done (and easier to understand than even their paper)”
Lecture on Paxos from the Raft user study.
Full comment
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 zab yourself, at this point, would be a futile exercise.) i found the videos from the raft user study to be very well done (and easier to understand than even their paper): raft: link paxos: this video ...however, i think they did paxos a disadvantage by not just focusing on multi-paxos (which is probably the most common implementation). but, it's certainly fair to say that info about paxos is spread out far and wide...with perhaps too many knobs to turn and implementation-related details to fill in yourself. as a side note: i've just started implementing raft in a set of libraries (multiple languages) that will be open source - along with other protocols.
RecommendspkjNov 2013
“A really good intro to Raft”
Good intro to Raft with clear practical examples.
Full comment
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.
Recommendssathish316Aug 2025
“gives a solid explanation of Raft internals”
Solid explanation of Raft internals by its creators.
Full comment
This YouTube video by the Raft creators (linked at the bottom of the page) gives a solid explanation of Raft internals - this video
Cites ittomjohnson3Sep 2013
“log entries on a follower may get rolled back - and thrown out - since they were not accepted on a majority of followers.”
Explains log repair during leader election.
Full comment
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 itdeathanatosSep 2014
“there's also a YouTube talk here”
Talk accompanying slides explaining how Raft handles elections and conflicts.
Full comment
> 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 purpose of the protocol.) > Considering it basically relies on random chance (I.E. who receives the message first) to elect a master, has basically no real way of resolving a conflict in election This is mostly true. The PDF slides I link to below recommend that the election timeout be much greater than the broadcast time, the idea being that things should work out in the long run. Highly recommend the PDF slides here, as they explain it better than I can: link — there's also a YouTube talk here: this video > Considering all that, this protocol doesn't seem very interesting (from a use-case point of view). I'd love to hear of alternatives.
Cites itnieksandSep 2014
“implementing the Raft consensus protocol could be neat too. It was designed to be understandable and implementable.”
Raft video as an understandable protocol to implement.
Full comment
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 itthrowawaybbq1Apr 2021
“One of the most impressive ways I have seen this being done by grad students was a user study by John Ousterhout and others on Paxos vs. Raft.”
Example of a well-designed user study comparing Paxos and Raft.
Full comment
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 user study by John Ousterhout and others on Paxos vs. Raft. IIRC, they wanted to claim that Raft was more understandable or led to fewer bugs. Their study design was excellent. See here for an example: this video ]
Cites itignoramousJul 2021
“Raft is very similar to Multi-Paxos.”
Part of user studies comparing understandability of Raft and Paxos.
Full comment
Raft is very similar to Multi-Paxos. These Raft and Paxos user studies comparing the "understandability" of the two protocols might be helpful: link (Paxos), this video (Raft). See also, comparison of various "Paxos" implementations: link
