Skip to content
HHackerTube.videoSurprise me

Raft lecture (Raft user study)

Raft lecture (Raft user study) on HackerTube: recommended by 4 Hacker News commenters across 4 separate months, 2013–2025.

Diego Ongaro

lecture · intermediate · evergreen

Open on YouTube

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 recommends it

HN commenters recommend it as a clearer introduction to Raft than the paper and as part of a well-designed understandability study.

people recommended it
4
separate months
4
strong recommendations
1
discussed on HN
2013–2025
“The 2 videos do an excellent job of explaining both the Paxos and Raft algorithms and the key differences between them.”
— krat0sprakhar, Oct 2014, in “The Raft Consensus Algorithm”

What HN commenters said

9 Hacker News comments link this video. Each one links back to its thread.

krat0sprakharOct 2014Strongly recommends

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]

in “The Raft Consensus Algorithm” · View on HN

sathish316Aug 2025Recommends

This YouTube video by the Raft creators (linked at the bottom of the page) gives a solid explanation of Raft internals - ▶ this video

in “The Raft Consensus Algorithm (2015)” · View on HN

pkjNov 2013Recommends

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.

in “The Writings of Leslie Lamport” · View on HN

tomjohnson3Sep 2013Recommends

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.

in “ZooKeeper vs. Doozer vs. Etcd” · View on HN

ignoramousJul 2021Cites it

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]

in “Paxos vs. Raft: Have we reached consensus on distributed consensus?” · View on HN

throwawaybbq1Apr 2021Cites it

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 ]

in ““They introduce kernel bugs on purpose”” · View on HN

Show 3 more comments
deathanatosSep 2014Cites it

> 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.

in “Raft: Understandable Distributed Consensus” · View on HN

nieksandSep 2014Cites it

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]

in “Ask HN: Final year project in CS” · View on HN

tomjohnson3Sep 2013Cites it

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.

in “ZooKeeper vs. Doozer vs. Etcd” · View on HN

Topics & tags

Distributed systemsUniversity lectures & coursesraftpaxosleader electionjohn ousterhoutdistributed systems