Raft's vote rule compares the term of a candidate's last log entry before it compares log length. Why not just elect whoever has the longest log?
Because the longest log can be the least trustworthy one. Picture a leader that gets partitioned onto the minority side of the cluster. It doesn't know it has lost, so it keeps accepting client writes and growing its log. Meanwhile the majority side elects a new leader and moves on.
That seems to contradict "a write needs a majority." It doesn't, because a write is really two steps:
- Append: the leader writes the entry to its own log and ships it to whichever followers it can reach. No quorum needed.
- Commit: once a majority has the entry, the leader applies it and only then tells the client it succeeded.
So the cut-off leader appends forever and commits never. Its clients time out and retry against the new leader. Its long log is all uncommitted draft. If length decided elections, that log could win when the partition heals and overwrite entries the majority really committed. Comparing the last entry's term first prevents that.
I'd been picturing writes as stop-and-wait: nothing lands anywhere until the quorum agrees. Separating append from commit is what made the vote rule make sense to me.
Details are in the Raft paper, §5.3–5.4.