Quando um site ou aplicação começa a receber mais acessos, o “servidor único” vira um ponto de falha e também um gargalo. Balanceamento de carga e alta disponibilidade (HA) são duas práticas que resolvem isso: distribuem as requisições entre múltiplos servidores e mantêm o serviço no ar mesmo quando um nó falha.
Antes de ir para ferramentas, vale entender a diferença: balanceamento de carga trata de performance e escala (dividir tráfego); alta disponibilidade trata de continuidade (evitar indisponibilidade). Na prática, você costuma implementar os dois juntos: um balanceador na frente e múltiplas instâncias/servidores atrás, com verificação de saúde e mecanismos de failover.
Arquitetura base (camadas): 1) DNS aponta para o serviço; 2) um balanceador de carga recebe as conexões; 3) um pool de servidores web/app processa requisições; 4) camadas de dados (cache, banco, storage) devem ser planejadas para não virar novo ponto único de falha. A parte mais ignorada por iniciantes é justamente o estado: sessão de usuário, uploads e cache precisam ser compartilhados ou externalizados.
Algoritmos comuns de balanceamento
Round-robin (distribuição sequencial), least connections (manda para quem tem menos conexões ativas), IP hash(mantém consistência por IP) e variações com pesos (ponderado). Para aplicações com carga desigual por rota, o least connections ou pesos por backend costuma funcionar melhor do que round-robin puro.
Health checks: o coração do HA
O balanceador precisa saber se um backend está saudável. Isso pode ser: checagem TCP (porta aberta), HTTP (status 200 em /health) e checagem mais profunda (dependências, banco, fila). Uma boa prática é criar um endpoint /healthsimples e outro /ready (pronto para receber tráfego), evitando mandar usuários para instâncias que “subiram” mas ainda não estão prontas.
Session persistence (sticky sessions): usar ou evitar?
Em alguns cenários, manter o usuário sempre no mesmo servidor simplifica (aplicações legadas). Mas isso reduz a eficiência do balanceamento e complica failover. Sempre que possível, prefira sessões stateless (JWT) ou sessões em um repositório compartilhado (Redis/Memcached), para que qualquer nó possa atender qualquer requisição.
Terminação TLS e headers corretos
Muitos ambientes terminam o HTTPS no load balancer. Nessa configuração, é essencial repassar informações para o backend por headers como X-Forwarded-For (IP do cliente) e X-Forwarded-Proto (http/https). Sem isso, logs, rate limit, redirecionamentos e regras de segurança podem se comportar errado.
Alta disponibilidade do próprio balanceador
Um erro comum é criar redundância nos servidores web, mas manter um único balanceador. Em ambientes on-premises, costuma-se usar dois balanceadores (ativos/passivos ou ativos/ativos) com VIP (endereço virtual) e failover via VRRP (ex.: Keepalived). Em cloud, serviços gerenciados normalmente já oferecem redundância interna.
Onde isso aparece na prática (cloud e hospedagem)
Em AWS, é comum usar um Elastic Load Balancing (ALB/NLB) com Auto Scaling para aumentar/reduzir instâncias; em hospedagens com painel, você pode combinar um proxy reverso (como Nginx/HAProxy) com múltiplos nós e storage compartilhado. Se você está construindo uma base sólida em infraestrutura, faz sentido estudar tanto o lado de nuvem quanto o de administração tradicional.
Para aprofundar trilhas relacionadas, veja a categoria de TI:
https://cursa.app/cursos-online-informatica-ti-gratuito
e a subcategoria específica:
https://cursa.app/curso-redes-de-computadores-online-e-gratuito
Para estudar fundamentos que ajudam a tomar decisões melhores em HA, vale também revisar:
https://cursa.app/cursos-gratuitos-online/basico-em-redes-de-computadores
Checklist rápido de implementação
- Defina objetivo (escala, tolerância a falhas, custo).
- Garanta que a aplicação suporte múltiplos nós (sessão, upload, cache).
- Configure health checks e timeouts corretos.
- Ajuste logs e headers de proxy.
- Planeje o HA do balanceador (ou use serviço gerenciado).
- Teste falhas: desligue um backend, simule queda de zona, valide tempo de recuperação.
- Monitore métricas: latência, erros 5xx/4xx, conexões, saturação.
Boas práticas que fazem diferença
Usar deploy gradual (blue/green ou canary), limitar conexões por backend, ativar compressão onde faz sentido, definir limites de upload e manter observabilidade (métricas, logs e traces). Para referências gerais sobre conceitos de disponibilidade e desenho resiliente, a documentação da Cloudflare traz um bom panorama:
https://www.cloudflare.com/learning/performance/what-is-load-balancing/
Ao dominar balanceamento de carga e HA, você ganha liberdade para crescer: adicionar nós deixa de ser um “evento” e passa a ser rotina. O resultado é uma infraestrutura mais previsível, resiliente e pronta para atender picos sem sacrificar a estabilidade.
