# Raft Safety: Election Restriction and Leader Completeness — Distributed Systems & Consensus (Raft / Paxos)

Source: https://www.skillbyai.com/en/distributed-consensus/dc-raft-safety

> Explain why a committed entry is never lost across leader changes and how the voting rule enforces it.

## The guarantee that ties it together

Raft's key safety property is **Leader Completeness**: if an entry is committed in some term, it is present in the logs of all leaders of later terms. It follows from two rules you have already met. First, a committed entry sits on a majority. Second, the **election restriction**: a voter refuses any candidate whose log is less up-to-date than its own. A winning candidate needs votes from a majority, and that majority overlaps the majority holding the committed entry, so at least one voter has the entry. That voter would refuse a candidate missing it, so the winner must already have it. Combined with Log Matching and the current-term commit rule, this gives **State Machine Safety**: if a server has applied an entry at an index, no other server ever applies a different entry at that index. Notice the shape of the argument: it is the same quorum-intersection reasoning as Paxos, applied to elections.

## Elections Raft must survive

Classic edge cases to rehearse: a leader that crashes after replicating an entry to a minority (the entry may be lost, which is fine because it was never committed); a leader that crashes after committing but before telling followers (the next leader still has it); and a partitioned old leader that keeps accepting writes it can never commit.

## The class register

To become class representative, you need signatures from a majority of the class, and each student signs only for someone whose attendance register is at least as complete as their own. Any important entry already recorded by a majority therefore always ends up in the new representative's register.

**Quiz:** Which rule ensures a newly elected Raft leader already holds every committed entry?

- [ ] Followers forward their logs to the candidate before voting
- [ ] Leaders replay the whole log from a snapshot after election
- [x] Voters reject candidates whose logs are less up-to-date than their own
- [ ] Only the server with the lowest ID may become leader

*Answer:* Voters reject candidates whose logs are less up-to-date than their own. The election restriction combined with majority overlap guarantees the winner's log contains all committed entries.
