Leader Election

Leader Election chooses one instance from a group to act as the coordinator while the others stand by. Some tasks must be performed by exactly one node at a time: managing a shared resource, scheduling jobs, or aggregating state. Running them on every instance would cause conflicts or duplicate work. Leader election ensures a single leader holds that responsibility, and that a new leader is chosen automatically if the current one fails.

How It Works

Instances participate in an election, typically backed by a coordination service that provides a consistent, fault-tolerant store. A common approach uses a lease or ephemeral lock: the instance that acquires it becomes leader and must keep renewing it. If it stops renewing (crash, network partition), the lease expires and another instance acquires it, becoming the new leader. Consensus algorithms such as Raft or Paxos provide the underlying guarantees in systems like etcd, ZooKeeper, and Consul.

The leader performs the coordinated work; followers stay ready to take over. Designs must handle the brief window where two nodes might believe they are leader (split brain) using fencing tokens or short leases.

Followers typically watch the leader's lease key and are notified the moment it is released, so a new election happens promptly rather than on a slow poll. Well-behaved leaders also voluntarily step down if they lose connectivity to the coordination service, narrowing the window in which a partitioned old leader and a freshly elected one could both act.

When to Use It

Use leader election when a task must be done by exactly one instance at a time but the system must remain available if that instance fails: distributed schedulers, partition coordinators, and primary-replica promotion. It provides single-coordinator semantics with automatic failover.

If work can be safely shared or partitioned across all instances, you may not need a leader at all.

It is also appropriate when you want active-passive redundancy: the leader does the work while standbys stay warm and ready to take over instantly on failure.

Trade-offs

Election adds dependence on a coordination service and introduces failover latency during which no leader acts. Split-brain scenarios must be guarded against with fencing or strict leases. The leader can become a bottleneck or single point of work. The benefit is correct, conflict-free coordination with resilience. To stay safe, the work the leader performs should carry the lease or fencing token so the protected resource can reject a stale leader, turning a potential split-brain into a harmless rejected operation.

Related Patterns

Leader Election is closely related to the Distributed Lock; a lock with a lease is one way to elect a leader. Consistent Hashing distributes work without a single coordinator. Health checks and a Service Registry support failure detection.

Example

A cluster of three scheduler instances must run cron jobs exactly once. Each tries to acquire a lease key in etcd. The one that succeeds becomes leader and runs the jobs, renewing its lease every few seconds. If it crashes, the lease expires after its TTL and another instance acquires it and resumes scheduling, so jobs keep running without duplication.