System Design/02 - Componentes/Load Balancers2 min
Load Balancing Algorithms
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Como o balanceador escolhe o backend de cada requisição.
| Algoritmo | Como decide | Bom quando |
|---|---|---|
| Round Robin | Rodízio na ordem | Backends homogêneos, requisições uniformes |
| Weighted Round Robin | Rodízio proporcional ao peso | Máquinas de capacidades diferentes |
| Least Connections | Quem tem menos conexões ativas | Requisições de duração variável |
| Weighted Least Connections | Idem, ponderado por capacidade | Frota heterogênea |
| Least Response Time | Menor latência recente | Backends com desempenho desigual |
| IP Hash | Hash do IP do cliente | Afinidade sem cookie |
| Consistent Hashing | Hash com anel virtual | Cache, sessão, sharding |
| Random / Power of Two Choices | Sorteia dois, escolhe o melhor | Escala grande, quase ótimo e barato |
Consistent hashing — por que importa
Com hash simples (hash(chave) % N), mudar N remapeia quase todas as chaves. Num cluster de cache, adicionar um nó invalida praticamente tudo de uma vez — e o banco leva o impacto.
Consistent hashing distribui nós num anel; adicionar ou remover um nó remapeia apenas 1/N das chaves. Nós virtuais corrigem a distribuição desigual que o anel puro produz.
Power of two choices
Sortear dois backends e mandar para o menos carregado chega perto do ótimo com custo quase zero — muito melhor que aleatório puro, sem o estado global que "least connections" exige. É a escolha padrão em balanceadores modernos de larga escala.
Trade-offs
Round robin é simples e ignora que as requisições têm custos diferentes: um backend que pegou três requisições pesadas continua recebendo na mesma cadência de quem pegou três triviais.
Least connections resolve isso e exige estado — o balanceador precisa contar conexões, o que fica caro quando há vários balanceadores que não compartilham essa visão.
Least response time é o mais adaptativo e tem um modo de falha traiçoeiro: um backend que falha rápido parece o mais saudável e atrai todo o tráfego. Sem health check bom, o algoritmo direciona os usuários exatamente para o servidor quebrado.
Sticky session por IP hash quebra com NAT (um escritório inteiro vira um IP) e com clientes móveis que trocam de rede.
Exemplo prático
Um cluster de cache com 4 nós recebe um quinto.
Com hash % N: hash % 4 vira hash % 5, e ~80% das chaves mudam de nó. O hit rate despenca perto de zero, e todo esse tráfego cai no banco de uma vez — um incidente causado por uma operação que parecia rotineira.
Com consistent hashing: apenas ~20% das chaves migram. O hit rate cai de 95% para ~76% e se recupera em minutos. A mesma operação, sem incidente.
Relacionado
Parte de Load Balancers · roadmap.sh/system-design