System Design/04 - Cloud Design Patterns/Design & Implementation2 min
Leader Election
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Eleger uma instância entre várias para executar uma tarefa que não pode ser feita em paralelo.
instâncias A, B, C
↓ eleição
B é o líder → executa o job agendado
A, C ficam em espera, prontas para assumir
Quando é necessário
- Job agendado que não pode rodar N vezes (Schedule Driven)
- Consumidor único de um recurso externo
- Coordenador de particionamento ou rebalanceamento
- Escritor primário numa replicação single-leader
Como se faz
| Mecanismo | Nota |
|---|---|
| Lock distribuído com TTL | Redis, banco. Simples e sujeito a expiração no meio |
| Consenso (Raft, Paxos) | etcd, ZooKeeper, Consul. Correto e mais pesado |
| Lease | O líder renova periodicamente; sem renovação, expira |
| Primitiva do orquestrador | Kubernetes Lease, eleição do próprio framework |
Trade-offs
O problema central não é eleger — é garantir que só existe um líder.
Split-brain: durante uma partição de rede, dois nós podem se considerar líderes e executar a mesma tarefa. Se ela não for idempotente, o efeito é duplicado — cobrança dupla, e-mail duplicado, escrita divergente.
O caso mais sutil é o lock expirado no meio do trabalho: o líder pega o lock com TTL de 30 s, o processamento demora 45 s, o lock expira, outro nó assume — e agora dois executam. As defesas são renovar o lease durante o trabalho e usar fencing token, um número crescente que o recurso protegido verifica, rejeitando escritas de um líder antigo.
O segundo trade-off é de disponibilidade: o líder é um gargalo e um ponto de falha. Durante a janela entre a morte do líder e a eleição do próximo, a tarefa não acontece. TTL curto reduz essa janela e aumenta o risco de eleição desnecessária sob carga.
E a recomendação prática: não implemente do zero. A eleição correta é difícil, e etcd, ZooKeeper ou a primitiva do orquestrador já resolvem o caso.
Exemplo prático
Três instâncias de uma aplicação, com um job de cobrança que deve rodar uma vez por dia.
Sem eleição, as três executam e o cliente é cobrado três vezes.
Com lock distribuído: às 3h, as três tentam adquirir lock:cobranca:2026-08-26 com TTL. Uma consegue e executa, renovando o lease enquanto trabalha; as outras não conseguem e não fazem nada.
O detalhe que evita o desastre mesmo assim: a cobrança em si é idempotente, com chave por cliente e período. Se a eleição falhar por qualquer motivo, o resultado é uma tentativa rejeitada, não uma cobrança dupla. Eleição protege; idempotência garante.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design