/ THE IDEA
The elected coordinator is called the leader. It adds each operation to an ordered list called a log and sends it to the other servers, called followers. An operation can become committed after a majority stores it under Raft’s rules. Any two majorities share at least one server. Raft combines that overlap with voting rules that reject a candidate whose log is less up to date. Together, the overlap and log rules preserve committed entries when leadership changes.
THE FORMAL IDEA
quorum = floor(N ÷ 2) + 1
| N = number of voting servers | | floor drops the fraction | | quorum = smallest strict majority whose stored copies can support commitment under the protocol’s other rules |
|
RUN THE TINY EXAMPLE
Split three servers into 2 + 1
Cluster A, B, C needs 2 votes to commit Network split: A+B can elect an eligible leader and continue C alone cannot commit a competing history
|
Availability is deliberately sacrificed on the minority side so the system does not tell two different groups that incompatible updates are both final.
/ SO WHAT?
This explains why a distributed service may reject writes even though one server is visibly alive. Safety sometimes requires saying ‘I cannot prove a majority agrees, so I will wait.’
ONE CAVEAT |
| Basic Raft handles crashes and unreliable networks, not malicious Byzantine servers. Consensus also orders operations; application-level transactions and business correctness still need separate design. |
KEEP THIS
Quorum overlap plus Raft’s log rules prevent an isolated minority from finalising a second history.
|
NEXT: Put E = mc² in your pocket
|