Consensus, Raft, Distributed Locks, and Leader Election

Two salaries, and five friends choosing dinner

Deepa runs payroll software for a company with 4,000 employees. The nightly salary job must run exactly once. She runs it on three servers for safety, so that if one dies, another takes over. One night a network hiccup makes two servers each believe they are in charge, and both run the job. Four thousand people are paid twice. (Deepa, the company and every number here are made up for teaching.)

Deepa needs her servers to agree on who is in charge, even when machines crash and messages vanish. Her friends solve the same problem every Friday. Five friends must agree on one restaurant by text message. Messages can be delayed or lost, and any phone may die.

Their rule: propose a place, and go only if a majority (three of five) replies yes. Two rival proposals can't both get a majority, because any two majorities share at least one friend, and that friend only says yes once per round.

flowchart LR
    subgraph M1["Majority for Biryani House"]
        A@{ icon: "algomi:svc-cube", label: "Asha", pos: "b", h: 52 }
        B@{ icon: "algomi:svc-cube", label: "Bilal", pos: "b", h: 52 }
        C@{ icon: "algomi:svc-cube", label: "Chitra", pos: "b", h: 52 }
    end
    subgraph M2["Majority for Dosa Corner"]
        C2@{ icon: "algomi:svc-cube", label: "Chitra", pos: "b", h: 52 }
        D@{ icon: "algomi:svc-cube", label: "Dev", pos: "b", h: 52 }
        E@{ icon: "algomi:svc-cube", label: "Esha", pos: "b", h: 52 }
    end
    C -.same person, can only vote once.- C2

Reading the diagram. For both restaurants to win, both groups of three would need Chitra's yes. She votes once per round, so only one restaurant can reach three votes. With five people, any two groups of three must overlap. This majority overlap is the core of consensus.

Deepa's fixes follow one at a time: