| I have had the opposite trajectory. Used to teach Paxos, but was so relieved to switch to Raft when the paper came out. I discuss distributed data structures in the context of maps and sequences. For maps, I discuss key-value stores (NUMA, Redis). I have them implement cache coherence (MESI protocol, TARDIS 2.0), then linearizable, fault-tolerant, wait-free shared memory registers (the Attiya/Bar-Noy/Dolev algorithm[1]). For sequences, I cover shared logs and state machine replication, including database log shipping, Kafka, queues and Raft. I like Raft because it cuts down the design space by making certain very intuitive and pragmatic choices, like using timeouts (which are almost beneath Lamport to discuss :), or idioms like "follow the leader", "if the leader is unreachable, stand for election", "elect the latest & most informed leader", (how I wish that was true in real life!), "always append" etc. There are simple mechanisms to preserve invariants. The problem with Paxos is that there is such a large range of papers that there is no one paper that makes the leap in easy digestible chunks from Basic to MultiPaxos. When I got students to implement MultiPaxos, I never could get sufficient confidence that it was done right (esp. the "disorderly" filling in of log slots). Paxos is like Monads; when you get it, you feel compelled to write a "Paxos explained" paper :) [1]https://groups.csail.mit.edu/tds/papers/Attiya/PODC90.pdf |
Raft essentially only allows a single mode. Moreover, you are starting to see people putting things on top of Raft instead of something like Paxos, in the enterprise, because they don't know any better nor have the foundation to understand what they are doing is "wrong."
> When I got students to implement MultiPaxos, I never could get sufficient confidence that it was done right
Testing this is fairly straightforward, they should be able to join an already existing cluster. If they got it wrong, it shouldn't take down the cluster, and they should be able to step through their own code. There aren't any timeouts, so they can take their time, going through each step of the process until a value is committed.
At that point, you simply explain each step as an individual algorithm, not the sum of its parts. You can even build each part individually because an existing cluster should recover from a misbehaving peer.
From there, it is a rather simple visualization process to see what is going on.
The hard part of paxos is building it from scratch.