I recommend Raft as the first consensus algorithm to learn because the leader and follower model matches how many engineers already reason about systems. It makes the hard parts visible without burying the idea in math.
The leader makes ordering visible
When I talk about "The leader makes ordering visible", I am really asking what Raft Consensus does when a message is late, duplicated, or missing.
Clients send commands to the leader. The leader appends each command to its log and sends it to followers. When a majority has the entry, the leader commits it and tells followers to apply it.
Leader election example
I use "Leader election example" to keep Raft Consensus grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
A configuration store changes the timeout value from 3 seconds to 5 seconds. The leader writes the change to its log, followers copy it, and the cluster commits the new setting.
Raft state code
When I show "Raft state code", I want the code in Raft Consensus to reveal the production decision, not just the syntax.
The leader commits only after enough followers have the entry:
LogEntry entry = log.append(command);
int acknowledgements = followers.replicate(entry);
if (hasQuorum(acknowledgements + 1, cluster.size())) {
log.commit(entry.index());
}The leader appends the command, replicates it, and commits only after quorum. Without that majority, the entry is not safe to treat as durable cluster state.
Sequence diagram: commit through the leader
The command becomes real after a majority has the log entry, not merely when the leader receives it.
The agreement boundary
- Use consensus for decisions that need one agreed answer.
- Keep the consensus path small and boring.
- Do not place every high volume business event on a consensus path.