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
I use this section to force the failure case into the conversation, not just the clean path.
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
This is where the concept becomes useful to me: it has to explain what a team does during a bad day.
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
I use the code here to show the decision boundary, not just 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.