Raft is a consensus algorithm. Its one job is to make a group of servers behave like a single, reliable one — even though the individual machines crash, reboot, and lose messages to each other along the way.
Why would you want several servers instead of one? Because if one machine holds your data and it dies, you're offline and possibly your data is gone. So you run copies on several machines. But that creates a new problem: the copies have to stay identical. If each one accepts requests on its own, they slowly drift apart, and now you have three servers each insisting on a different version of the truth.
Raft's trick is to not copy the data directly, but to copy the list of commands that produced it — an ordered log, like set x=7, then del a, then inc n. If every server applies the exact same commands in the exact same order, they all end up in the exact same state. So the entire challenge boils down to one thing: getting every server to agree on that single, growing, ordered log. That agreement is what "consensus" means.
Three design choices carry the whole algorithm, and each one answers a specific danger:
Why elect a single leader? Someone has to decide the order of commands. Raft picks one server — the leader — as the only place commands are allowed to enter the log, so there's never an argument about ordering. Older algorithms (famously Paxos) let every server propose at once, which works but is notoriously hard to reason about. Raft was designed first and foremost to be understandable, and a clear leader is most of that.
Why does everything hinge on a "majority"? Any two majorities of the same cluster must share at least one member — three-of-five and a different three-of-five always overlap somewhere. That single shared member is what makes it impossible to elect two leaders at once or to "forget" a decision a majority already made: someone in the overlap always remembers. That's why the magic threshold is more than half, and why a cluster of five survives two failures but not three.
Why the ever-increasing "term" number? A crash or a slow network can leave an old leader that still thinks it's in charge. The term is a simple logical clock the whole cluster shares: the instant any node sees a higher term than its own, it knows it's working from stale information and steps aside. It's how the cluster tells "current reality" from "a message from the past."
With that in hand, the walkthrough below shows these ideas actually playing out — election, replication, a crash, and recovery. First, the three roles a server can be in:
The default. Passive — it only answers messages. Hears nothing from a leader for a while, and it suspects the leader is gone.
A follower whose patience ran out. It bumps the term counter and asks everyone to vote for it. Win a majority and it becomes leader.
The single node clients talk to. It appends commands and pushes copies to everyone, sending steady heartbeats so no one starts a new election.
—
Tip: use the ← and → arrow keys too.
Everything in the walkthrough above follows from these.