Every system that promises "strongly consistent and highly available-ish" — etcd under Kubernetes, Consul, CockroachDB, TiDB — has a consensus algorithm at the bottom, and these days it's almost always Raft. Raft's claim to fame is being understandable, so let's take it at its word: one diagram, one write, start to finish.
This diagram is a real techdiagrams document — download the JSON and import it into the editor via File → Import.
One leader, one term, one log
Raft's first simplification: all writes go through a single leader. No multi-master conflict resolution, no vector clocks — at any moment the cluster has exactly one node allowed to accept writes, elected for a numbered term (our diagram is in term 7).
When the client sends write x=5:
- The leader appends the entry to its own log — uncommitted.
- It ships the entry to every follower in an AppendEntries RPC (the same message type doubles as the heartbeat when empty).
- Each follower appends and acks.
- The moment a majority — 3 of our 5 nodes, leader included — has the entry, it's committed: the leader applies it and answers the client.
Note what that majority rule buys in the diagram: Node E is slow, still catching up over its dashed link. Nobody waits for it. Two dead or lagging nodes are simply survivable; the write path only ever moves at the speed of the third-fastest node. That's the availability half of the deal.
Elections: what happens when the leader dies
The consistency half comes from how leadership changes hands. Followers expect heartbeats. If a follower hears nothing for a randomized election timeout (typically 150–300ms), it assumes the leader is gone, increments the term, votes for itself, and asks the others for votes.
Two rules make this safe:
- One vote per term per node — so two candidates can't both win the same term. Majorities can't overlap without sharing a node, and that shared node voted only once.
- Votes go only to candidates whose log is at least as up-to-date as the voter's — so a stale node can't get elected and overwrite committed entries. Anything committed lives on a majority, and any electable candidate must be at least as current as some member of that majority.
The randomized timeout is the quietly brilliant bit: it makes split votes rare (someone times out first), and when they do happen, everyone re-rolls the dice next term. No coordination needed to avoid coordination failure.
What Raft costs you
Consensus is not free, and honest architecture means knowing the bill:
- Every write pays a round-trip to a quorum. Cross-region Raft means cross-region write latency — put replicas in three zones, not three continents, unless you mean it.
- The leader is a throughput ceiling. All writes funnel through one node; systems like CockroachDB shard into many Raft groups precisely to escape this.
- Losing a majority halts writes entirely. Raft chooses consistency over availability in a partition — 2 of 5 nodes alive means a read-only (or fully unavailable) cluster. That's a feature, and it should be a conscious choice.
Try killing the leader yourself
This is exactly the kind of design that reads fine on paper and surprises you in the failure cases — which is why it makes a great simulation. Import the diagram into techdiagrams.net, and you have a living starting point: attach contracts, declare "no acknowledged write is ever lost," and experiment with what a leader crash between append and commit does to your assumptions. Consensus is much stickier once you've watched it break.