Leader election
How distributed systems pick one node to be in charge and replace it safely when it fails: why leaders are useful, leases and heartbeats, consensus with Raft, using etcd, ZooKeeper, Consul or Kubernetes leases instead of building your own, database-based locks, fencing tokens against split brain, and when to avoid needing a leader.
CodexBash, , 6 min read
Many systems need exactly one node to do something: run a scheduled job once rather than on every instance, accept writes for a database partition, assign work to others, or coordinate a cluster. Choosing that node, and choosing a new one when it fails, is leader election. It sounds simple until you remember that networks drop messages, clocks drift and processes pause, so a node may believe it is still the leader after the others have chosen someone else. This article explains how leader election works, the tools that implement it correctly, and the safeguards that make it safe.
Sign in to read the rest
The whole 6 minute article is free with an account, along with every problem, lesson and tutorial. No card.