Leader Election

Resumen

En muchos sistemas distribuidos, tener un líder simplifica la coordinación: un solo nodo toma decisiones —asignar trabajo, ordenar escrituras, mantener locks— y los demás lo siguen. El desafío es elegir ese líder de forma confiable: si el líder falla, debe elegirse uno nuevo rápidamente, y nunca debe haber dos líderes simultáneos —split-brain—.

Los algoritmos de consenso —Raft, Paxos— incluyen leader election como subproblema. Otra aproximación es usar un servicio externo con consistencia fuerte —etcd, Zookeeper— y locks o leases para decidir quién es el líder.

Alcance y supuestos

Cubre leader election como patrón, algoritmos y servicios que lo implementan. Asume familiaridad con sistemas distribuidos.

Modelo mental

Un equipo de fútbol sin capitán designado. Necesitan uno para hablar con el árbitro. El arquero dice «yo soy el capitán» —se autopropone— y los demás asienten. Si el arquero se lesiona, el defensor más experimentado toma el brazalete. En ningún momento hay dos capitanes.

Uso práctico

• ✅ Schedulers, bases de datos replicadas, procesamiento de streams.
• ❌ Sistemas stateless que no necesitan coordinación central.

Ejemplo trabajado: leader election con etcd

Tres instancias compiten por una key /leader. La que logra crearla primero es el líder. Las demás hacen watch. Si el líder no renueva el lease, la key expira y otra instancia la toma.

Evidencia

• etcd y Zookeeper son los servicios más usados para leader election. Kubernetes usa etcd para el líder del control plane.