Design the leader-election mechanism for a 5-node coordination service (think: who owns a distributed lock) so two nodes can never simultaneously believe they're the leader. Walk through Raft's actual safety mechanism — not 'nodes agree', the real one — and what a 2-3 network partition does to it.

Raft rules out two simultaneous leaders by counting votes, not by nodes somehow agreeing — every node votes at most once per term, and since a majority is more than half the cluster, two disjoint groups can never both gather a majority in the same term; any two majorities of the same set of nodes must share at least one node, and that node already spent its one vote on one side. This is pure arithmetic, not timing or luck. Applied to a 5-node cluster split 2-3 by a partition: the 3-node side can elect a new leader on its own (3 of 5 is a majority), while the 2-node side — even if it still has the original leader, alive and sending heartbeats — can never commit a new write, because committing needs a majority of the full cluster (3 of 5), and the old leader can only reach itself plus 1, which is 2. The old leader keeps accepting client writes into its own log, but they sit uncommitted forever until, once the partition heals, it discovers the new leader's higher term and steps down.