Raft was designed to be understandable — Paxos's correctness with a teaching-friendly structure. If you can hold three ideas in your head — leader election, log replication, safety constraint — you understand Raft well enough to reason about etcd, Consul, CockroachDB, and TiKV behavior.
Three states: follower, candidate, leader
Most nodes are followers. If they don't hear from a leader within a randomized timeout, they become candidates and start an election. The candidate that wins a majority becomes leader. New leaders mean new term numbers — monotonically increasing.
Leader election
Random election timeout (150-300ms typical) prevents split votes. Candidate sends RequestVote RPC; receivers vote yes if (term > theirs AND haven't voted this term AND candidate's log is at-least-as-up-to-date). First to majority wins.
Log replication
Leader appends to its log, sends AppendEntries to followers, considers entry 'committed' when majority acknowledges. Commit index advances; state machine applies entries in order. Crash-safe: replayed on restart.
Safety: the log-up-to-date check
A candidate wins only if its log is at-least-as-up-to-date as a majority. This guarantees committed entries never get lost across leader changes. Without it, a node with stale log could win election and overwrite committed state.
Failure handling
Network partition splits cluster: only the side with majority can elect; the minority side stalls (which is correct — no split-brain). Leader dies: new election within ~300-500ms. Slow follower: leader retries AppendEntries until it catches up.