Why Raft exists
Raft exists because the algorithm that came first, and is provably correct, is notoriously hard to understand and harder to implement.
Raft was designed in 2013 with understandability as an explicit goal, and it won. The mainstream coordination stores all run it now.
Divide your time into numbered terms, each with at most one leader. Read a term number as a logical clock, not a wall clock, and it is what lets any machine recognise a stale message, because anything arriving with an older term gets discarded.
Give each of your machines one of three roles: follower, candidate or leader. Your leader sends heartbeats.
Watch one of your followers hear nothing for its election timeout. It assumes the leader is gone, increments the term, votes for itself, and asks the others for their votes. A machine grants its vote if it has not already voted this term and the candidate's log is at least as current as its own. Collect a majority and you are leader for that term, announced with a heartbeat.
Look at the detail that makes it work: randomised timeouts. If all your followers waited exactly 200 milliseconds, they would become candidates at once, split the vote, and repeat forever.
Have each of yours pick randomly in a range instead, typically 150 to 300 milliseconds, so one almost always times out first and wins before the others start. A split vote is not a failure. It means nobody reached a majority, and the next term retries with fresh random timeouts.
Writes use the same rule
Commit writes by the same majority rule. Your leader appends the entry to its log, sends it to the followers, and commits once a majority have written it to disk.
Notice why the two majorities have to overlap. Any future leader needs votes from a majority, and any majority includes at least one machine holding every committed entry, so committed data survives a change of leader. That single property is what makes the whole thing safe.
Your partitioned leader does not know it is partitioned. It keeps trying to replicate, never reaches a majority, so nothing it accepts is ever committed, and when it rejoins and sees a higher term it steps down.
Worked example
A 5-node etcd cluster is running term 41 with node 3 as leader. Node 3's host is taken down for a kernel patch at 02:14:07. Heartbeats stop. Node 1's randomised timeout fires first at 02:14:07.19, so it moves to term 42, votes for itself, and requests votes. Nodes 2, 4 and 5 each check that node 1's log is current, have not voted in term 42, and grant. Node 1 has 4 votes out of 5 and becomes leader about 240 ms after the old leader went quiet. Clients retry once and continue. When node 3 comes back at 02:31 it still believes it leads term 41, sends a heartbeat, receives a reply stamped term 42, and immediately steps down to follower and catches up its log. No human involved, and no window in which both nodes could commit anything, because node 3 could never have reached a majority while isolated.