Raft is the most widely used consensus algorithm in the world. It powers etcd (the brain of Kubernetes), Consul, and CockroachDB. It was designed in 2013 specifically to be easier to understand than the older Paxos algorithm.
Raft separates consensus into two distinct phases: Leader Election (which we just covered) and Log Replication.
Once a Leader is elected, it must serve all client requests. Every request to change data (e.g., SET x=5) is treated as a command to be added to a replicated log.
But the Leader can't just write x=5 to its database and reply "Success". If it did, and then immediately crashed, the data would be lost forever, because the followers wouldn't have it. Instead, Raft uses a Two-Phase Commit process:
You are acting as the client. Send a command to the Leader. Watch how the data flows from uncommitted (dashed) to committed (solid) across the cluster.
The magic of Raft is the Commit Index. This is just an integer that tracks the highest log entry that is safely stored on a majority of servers.
If the Leader crashes before getting a majority of ACKs, the new Leader elected will not have that uncommitted log entry. The uncommitted entry is simply overwritten. It's as if it never happened. This is why the client only gets a "Success" response after the majority commits.