Leader Election, Leases, and Consensus Basics
Distributed coordination is needed when multiple nodes must agree on ownership or a shared decision. Leader election chooses a node to coordinate a task, but a leader can pause, become partitioned, or lose connectivity while other nodes continue.
A lease grants ownership for a bounded period, yet clock drift and pauses can make stale owners dangerous. Fencing tokens solve an important class of stale-owner problems: each new owner receives a monotonically increasing token, and the protected resource rejects operations carrying an older token.
Consensus protocols such as Raft help a group of nodes agree on a replicated log despite certain failures, assuming a majority can communicate. Consensus is not a magic global lock; it has latency, quorum, membership, and operational constraints. Use established coordination systems rather than inventing a protocol for production.
If a process pauses past its lease and later resumes, it may still try to write. Fencing tokens or equivalent resource-side validation can prevent stale ownership from corrupting state.
- Leader election does not eliminate stale-leader risks.
- Fencing tokens protect resources from expired owners.
- Use proven consensus implementations and understand quorum assumptions.