Accessible Media Delivery Engine

In any fault-tolerant distributed system, nodes can be in one of three states: Follower, Candidate, or Leader. All nodes start out initially as Followers.

Followers remain completely passive as long as they receive regular heartbeat messages from an active leader. If heartbeats stop, the election timeout triggers.

To avoid split votes where two candidates start an election at the exact same millisecond, Raft introduces randomized election timeouts between 150 milliseconds and 300 milliseconds.

When a node transitions to the Candidate state, it increments the current term, votes for itself, and broadcasts RequestVote RPCs to all peers in the cluster.

If a candidate receives votes from a strict quorum—meaning more than half of the cluster nodes—it successfully becomes the cluster leader for that term.

Once elected, the leader immediately starts sending AppendEntries heartbeats to suppress new elections. Clients send all write requests directly to this leader node.

Next comes log replication. The leader appends the new entry to its log, broadcasts AppendEntries RPCs with the entry, and waits for quorum confirmation before committing.

Once the entry is safely replicated on a majority of nodes, the leader applies it to its local state machine and returns the result to the client application.

Notice how Raft maintains the Log Matching Property: if two entries in different logs have the same index and term, they are guaranteed to store the exact same command.

This guarantee ensures linearizable consistency even under network partitions, packet loss, or arbitrary follower node crashes.

In the next session, we will inspect leader crash recovery and log compaction with snapshots. Review the downloadable notes below before continuing.