Visualization author here. Cool to see it get some HN love despite being six years old.
Unfortunately, the visualization project is effectively dead. The Raft visualization involved a lot of painful D3.js coding and effectively writing a JS Raft implementation. In hindsight, a deterministic format would be much easier. I toyed around with learning After Effects in hopes of producing some other visualization videos but I never did finish any.
I'm glad folks are still getting value out of the Raft visualization. The paper is good but it helps to see data move over time to really make it click.
Well, just two weeks ago I was searching for a quick intro on how Raft works, because I heard it several times over the years, but never took the time to see how it actually works. I didn't really find something to digest quickly until I saw your page. Great work and thank you!
MIT online trainig has this great YouTube playlist on distributed systems, with one of the lectures being on RAFT [1,2,3]. The entire playlist [4] is probably worth your time, though.
I don't have any particular use for this right now but the visualization is so good that I actually followed along and get what it's about. Pretty obvious to say but it's super cool and I wish more projects had this kind of quick intro/overview.
I see from elsewhere in the thread that this was a painstaking/manual effort and leverages D3.
Does anyone know if there are projects/libraries to help build this kind of visualization more generically? I realize that no library could every cover every possible use case, but I'd love some kind of framework that makes it easy to build out this kind of thing.
Reveal [1] is great for a web-based slideshow, but I'd love something that helps explain complex systems, even if that requires me to do some heavy lifting.
Same! Raft is something I've heard about for years and always "wanted to get around to" learn, but this visualization just took care of most of that. Hoping there are other good visualizations like this in the future.
This visualization is very good. But the Raft paper itself is also quite understandable (and I say this as someone without any formal CS background who struggles getting through papers). It's main goal, aside from correctness, was understandability after all.
I'd estimate it took me about 2 hours to get through it, but it felt very satisfying because I walked away saying "yup, I see how this works now". Give it a shot!
Zookeeper is the standard one which has been around the oldest. Zookeeper is not based on raft, but it has similar semantics as etcd. So if you don't care about the impl, ZK may be good as well.
How does Raft handle the scenario where there’s a network split, Client One updates a value on the majority, and then Client Two attempts to read the value from the minority side?
I'll assume by "majority/minority" you mean a network partition where at least half plus one nodes are still able to elect a leader, while the remainder are not.
In vanilla Raft, reads are appended to the Raft log like writes are. This means in order to commit a write, the client and the leader on the "majority" side will update the value as normal. The second client will either be unable to find a leader to contact at all, or if it is connected to an old leader, the leader will not be able to replicate the log entry necessary to service the read from the second client.
There are lease optimizations that rely on bounded clock error that allow for performing reads from the leader without appending entries to the log. Note this relies on the rate at which the clock advances, not the actual time.
There are also optimizations from Paxos research that would allow reading from the followers, but those also require contacting the leader at minimum.
In summary, Client One will succeed and Client Two will fail.
Then client two can't read the new value until a least one node of the minority side can connect to the majority. Also client two can't update anything.
Basically if you want to replicate data across multiple nodes, all of them need to agree on the sequence of data updates. For example if I did [x=6, x=7], then the outcome of those ops is very different if I did it in the opposite order [x=7, x=6]. Easiest way to do this sequencing is to have a unique leader who will impose the unique order. Strict sequencing is not really serializability, but linearizability. For example, Cassandra doesn't by default have the concept of a leader and hence can't provide linearizability. Of course, there is a problem on how you decide who is the leader and what happens if two nodes think they are the leader at the same time. That's where the genius of Multi-Paxos/Raft comes in. You can read more about sequencing here
Raft is essentially Multi-Paxos under the hood, with some overstrict invariants that can impact availability and latency. If you need a consensus algorithm, then it's worth doing a survey of the literature beyond Raft.
Other Multi-Paxos variants are Viewstamped Replication Revisited, which has deterministic leader election for lower latency in the common case and thus no issue of split votes, and which I personally find easier to understand than Raft, also making less demands of the underlying hardware (i.e. VRR can do in-memory leader election, so you're safe in the event of disk failure, corruption, lost writes, and misdirected writes, which Raft does not deal with).
For all these Multi-Paxos variants, you can also look at Flexible Paxos, which is a simple technique for making leader election quorums slightly more expensive (since leader elections are infrequent) in order to make replication quorums much cheaper (since they are the common case critical path). You can use Flexible Paxos to save 20% in the number of hardware nodes for the same common case failure tolerance. Flexible Paxos is a game changer.
Unfortunately, the visualization project is effectively dead. The Raft visualization involved a lot of painful D3.js coding and effectively writing a JS Raft implementation. In hindsight, a deterministic format would be much easier. I toyed around with learning After Effects in hopes of producing some other visualization videos but I never did finish any.
I'm glad folks are still getting value out of the Raft visualization. The paper is good but it helps to see data move over time to really make it click.