Problem
Multiple instances of a service run for availability. Singleton tasks (cron, migration, cache warmer) must run exactly once.
coordinationestablished · low operational burden
Leader Election
Also known as: leader-elector, distributed-lock, coordinator
Intent
Ensure exactly one instance performs a task (scheduler, processor, migrator) in a distributed system.
Forces
- •Task must run even if one instance fails
- •Must not run twice (duplicate side effects)
- •Failover must be fast (seconds)
- •No single point of failure in election itself
Solution
✓ When to Use
- •Singleton background tasks (scheduler, migrator, aggregator)
- •Active-passive failover for stateful services
- •Distributed cron jobs
✗ When Not to Use
- •Stateless horizontal scaling (all instances should work)
- •Tasks that can run concurrently (partition instead)
- •When coordination backend unavailable
Pros
- +Exactly-one semantics with automatic failover
- +Built into coordination systems (etcd, Consul, K8s)
- +Observable: leadership changes are events
Cons
- −Split-brain risk if lease TTL too short / network partition
- −Failover latency = TTL + detection (typically 10-30s)
- −Coordination backend is single point of failure (mitigate: HA)
Cost Profile
Infrastructure
Low — uses existing coordination backend
Operational
Low — monitor leadership changes
Cognitive
Low — standard pattern
Failure Modes
Network partition: two leaders (split-brain) if TTL expired
GC pause > TTL → leadership lost spuriously
Coordination backend down → no election possible
Clock skew: lease expiry calculation wrong
Real-World Examples
Alternatives
- partitioned-workers
- distributed-lock
- cron-with-lock
Related Patterns
- distributed-lock
- partitioning
- cron-job
- health-check
Competency Domains
distribution communicationreliability opsdata state