O que é balanceamento de carga: guia prático

Balanceamento de carga é a prática de distribuir requisições e sessões entre vários servidores ou instâncias saudáveis, para que nenhum nó sozinho absorva todo o tráfego. O balanceador decide para onde cada fluxo vai, acompanha a saúde do pool e reduz o risco de lentidão ou queda quando o volume sobe ou quando uma máquina falha.

Imagine uma loja online na Black Friday, um app de delivery no almoço ou uma API pública que recebe picos sem aviso. Se todo o tráfego bate em um único servidor, a fila cresce, o tempo de resposta sobe e parte dos clientes vê erro ou timeout. O leitor que busca este verbete costuma estar montando um site, migrando para a computação em nuvem ou tentando entender por que o sistema aguenta em horário normal e morre no pico.

Ao terminar a leitura, você sabe o que o balanceador faz e o que ele não faz, quais tipos de balanceamento de carga existem na prática e quais armadilhas aparecem quando a distribuição de tráfego é mal desenhada. O texto prioriza critérios e riscos, não receita de ferramenta mágica.

Por que o balanceamento de carga existe em sites e APIs?#

Ele existe para espalhar o trabalho entre vários recursos de computação e assim melhorar uso de capacidade, vazão e tempo de resposta, sem concentrar tudo em um único ponto. A documentação de arquitetura da Microsoft descreve o balanceamento exatamente nessa linha, como distribuição de processamento entre vários recursos para otimizar uso, maximizar throughput, reduzir tempo de resposta e evitar sobrecarga de um só nó. Além disso, a mesma lógica aparece no ecossistema web, onde um servidor visível pode ser, por trás, um conjunto de máquinas que compartilham a carga.

No cotidiano, o benefício mais sentido é continuidade parcial sob falha. Se três instâncias atendem o mesmo serviço e uma cai, o balanceador para de enviar tráfego novo para ela, desde que haja verificação de saúde configurada. Porém o custo aparece logo, porque você passa a operar mais nós, mais configuração e mais superfície de falha operacional. Por outro lado, não balancear também tem preço, só que ele chega em forma de queda e suporte noturno.

Há ainda o caso em que o problema não é ataque, e sim pico legítimo mal dimensionado. O CERT.br lembra que sobrecarga por falta de escalabilidade não deve ser confundida com ataque DDoS, e recomenda avaliar capacidade e definir política de balanceamento de carga com opções como proxy reverso, balanceador externo, Anycast, GSLB e CDN nas recomendações sobre DDoS. Assim, o balanceamento entra como peça de resiliência, não como substituto de aplicação lenta ou banco mal indexado.

Na prática, o que eu vejo com mais frequência é time que compra capacidade extra sem olhar o gargalo real. O balanceador ajuda quando há várias cópias saudáveis do mesmo serviço. Se o gargalo for consulta pesada a um banco de dados único, só espelhar a camada web muda pouco o resultado percebido pelo usuário.

Como o balanceador de carga escolhe o servidor?#

O balanceador de carga, também chamado de load balancer, recebe a conexão ou a requisição e escolhe um membro do pool segundo regras e estado de saúde. Em muitos desenhos web, isso acontece por meio de um proxy reverso que encaminha o tráfego para vários backends. A MDN lista o balanceamento de carga entre vários servidores web entre os usos clássicos de proxy, junto de cache e compressão. Ou seja, o cliente fala com um ponto de entrada, e o proxy decide o destino interno.

Camada de rede e camada de aplicação#

Em camada 4, a decisão usa dados de transporte, como endereço e porta, sem inspecionar o conteúdo HTTP. Em camada 7, a decisão pode olhar caminho da URL, cabeçalhos e host, o que permite roteamento por rota ou por aplicação. No entanto, mais inteligência na decisão também significa mais complexidade, mais pontos de configuração errada e, em alguns casos, mais latência de processamento no caminho. Por isso a escolha da camada deve seguir o contrato do serviço, não o jargão do fornecedor.

Saúde do pool e afinidade de sessão#

Sem health check, o balanceador pode continuar enviando usuários para uma instância morta. Com health check, a instância doente sai do rodízio até voltar a responder. Porém a verificação precisa medir o que importa. Checar só se a porta TCP abre não prova que a aplicação está saudável. Além disso, sessões com estado local no servidor exigem afinidade ou estado externo, senão o usuário pula de máquina e perde carrinho, login temporário ou progresso de formulário.

O RFC 7098 trata da distribuição de carga em fazendas de servidores e lembra que, no contexto de server farm, balanceamento e distribuição de carga buscam espalhar o trabalho entre servidores distintos para otimizar desempenho. Em seguida, o documento discute balanceadores de camada 3 e 4 que atuam sobre pacotes IP e sessões TCP. Esse fundamento ajuda a entender por que a escolha do algoritmo e da camada importa tanto quanto ter um balanceador.

Se fosse comigo, eu documentaria primeiro o contrato do serviço. Preciso de sticky session. Preciso terminar TLS no balanceador. Preciso preservar o IP do cliente por conformidade ou auditoria. Sem essas respostas, a ferramenta certa vira chute caro.

Quais tipos de balanceamento de carga entram no dia a dia?#

Os tipos de balanceamento de carga mais citados no cotidiano de infraestrutura são o de servidor (L4 ou L7), o baseado em DNS e o global com Anycast ou serviços de borda. O de servidor distribui conexões ou requisições entre instâncias de um mesmo serviço. O baseado em DNS responde com endereços diferentes conforme política, região ou peso. O global tenta aproximar o usuário de um ponto saudável, muitas vezes combinado com CDN.

Cada tipo troca velocidade de reação por simplicidade. Balanceamento por DNS é fácil de explicar, porém a recuperação pode demorar porque caches de DNS e clientes que ignoram TTL atrasam a virada, ponto que a própria Microsoft destaca ao falar de balanceamento baseado em DNS no overview de opções. Já o balanceador L7 reage mais rápido a uma instância doente, mas exige operação contínua de regras, certificados e sondas.

Exemplo concreto ajuda. Um SaaS com três réplicas da API atrás de um load balancer L7 pode tirar do pool a réplica que falhou no health check em segundos. O mesmo SaaS só com rodízio de registros DNS pode continuar enviando parte do tráfego ao nó morto enquanto o TTL não expira. Por isso, DNS sozinho raramente basta para failover fino de aplicação.

Há também o encaixe com microserviços e containerização. Nesses desenhos, o balanceamento aparece em mais de um nível, do ingresso público até o serviço interno. O benefício é isolamento e escala independente. O risco é espalhar estado e observação em camadas demais, até ninguém saber qual hop está descartando requisição.

O erro que mais custa caro aqui é misturar tipos sem critério. Time coloca CDN, DNS geo e dois proxies em série, e depois não consegue explicar onde a sessão quebra. Comece pelo problema mensurável, por exemplo queda em um único nó no pico, e só então some camadas.

Como a distribuição de tráfego lida com falha e pico?#

A distribuição de tráfego bem feita combina pool redundante, sonda de saúde e margem de capacidade. Quando o volume sobe, novas requisições vão para nós com folga. Quando um nó falha, o fluxo novo evita esse nó. Assim o serviço degrada menos, embora o usuário ainda possa sentir lentidão se a capacidade total restante for insuficiente.

Nas mesmas recomendações de preparação contra DDoS já citadas do CERT.br, o balanceamento aparece amarrado a superdimensionamento, elasticidade sob demanda e avaliação de gargalos de aplicação, inclusive consultas lentas a banco. Portanto o balanceador não engole ataque ou pico por mágica. Ele redistribui o que a infraestrutura ainda consegue processar. Em ataque volumétrico extremo, entram também filtragem, scrubbing e acordos com provedor, com custos e impactos de confidencialidade que o próprio CERT.br alerta no uso de sinkhole e clean-pipe.

Algoritmos comuns e o que eles escondem#

Round-robin envia na sequência entre membros do pool e é simples de operar. Menos conexões ou menor carga enviam tráfego a quem está mais folgado, o que parece justo, porém a métrica errada engana. Hash de tupla tenta manter o mesmo fluxo no mesmo caminho, o que reduz reordenação e quebra de sessão, ideia alinhada à discussão de balanceamento de fluxos em redes na literatura de RFCs sobre multipath. Ainda assim, hash mal escolhido concentra muitos clientes grandes no mesmo backend.

Em uma simulação com premissas explícitas de 2026-10, quatro instâncias idênticas enfrentam um pico de 4.000 requisições por segundo, e cada uma segura, com folga, cerca de 1.200 rps sem degradar. Sem balanceamento, um único nó recebe tudo e satura, enquanto com distribuição uniforme ideal cada nó fica perto de 1.000 rps e sobra margem. Se uma instância cair e o health check demorar dois minutos para agir, os três nós restantes passam a cerca de 1.333 rps e a margem some. O exercício não prevê o seu ambiente, só mostra que failover lento vira pico artificial nos sobreviventes.

Muita gente acha que bastar ligar um balanceador resolve disponibilidade, e quase sempre está enganada, porque disponibilidade é capacidade restante mais tempo de detecção mais dependências compartilhadas. Disco cheio em todas as réplicas, certificado vencido no ingresso ou fila única no banco derrubam o serviço mesmo com load balancer impecável.

O que o balanceamento de carga não resolve sozinho?#

Ele não corrige aplicação sem cache onde o cache caberia, não elimina bug de condição de corrida e não substitui observabilidade. Também não garante segurança sozinho. Em muitos desenhos o balanceador termina HTTPS e encaminha para o backend, e aí cabeçalhos como Forwarded ou equivalentes passam a importar para a aplicação saber o protocolo e o host originais, tema documentado na MDN no cabeçalho Forwarded. Se a aplicação confiar cegamente em cabeçalhos forjáveis sem rede confiável, o ganho operacional vira risco.

Outro limite duro é estado. Balancear frontends sem externalizar sessão, arquivos locais ou jobs em disco cria comportamento às vezes funciona. O usuário cai em outra máquina e perde contexto. Além disso, custo operacional sobe com cada réplica, cada sonda, cada regra e cada alarme. Em equipe pequena, complexidade excessiva atrasa resposta a incidente.

Há ainda a falsa sensação de proteção contra abuso. Distribuir tráfego ajuda a absorver parte do volume, porém atacante grande ou bot sofisticado ainda exige controles na borda, firewall de aplicação quando couber, limites de taxa e processo com provedor. O balanceamento é peça, não escudo completo.

Quando eu reviso um ambiente em produção, o sinal de alerta costuma ser ausência de teste de falha. Ninguém derruba uma réplica de propósito em janela controlada, ninguém mede tempo até o health check agir e ninguém confirma se a sessão sobrevive. Sem esse ensaio, o desenho existe no slide e falha no feriado.

Termos relacionados#

• CDN (rede de distribuição de conteúdo) Aproxima conteúdo estático do usuário e pode absorver volume, com efeito distinto do balanceamento entre backends de origem.
• ataque DDoS Sobrecarga maliciosa que o balanceamento ajuda a diluir só até o limite da capacidade e das defesas de rede.
• computação em nuvem Ambiente em que balanceadores gerenciados e autoscaling costumam aparecer juntos, com custo variável.
• DNS (sistema de nomes de domínio) Pode participar do balanceamento global, com failover geralmente mais lento que um load balancer de aplicação.
• microserviços Arquitetura que multiplica pontos de balanceamento interno e exige disciplina de saúde e observabilidade.
• latência Métrica que o balanceamento busca reduzir em média, mas que pode subir se houver hops e inspeção demais no caminho.
• API (interface de programação de aplicações) Carga típica a ser distribuída quando várias instâncias expõem o mesmo contrato.

Perguntas frequentes sobre balanceamento de carga#

Antes das respostas curtas, vale alinhar o que costuma gerar dúvida depois da teoria. As perguntas abaixo cobrem definição, diferença para CDN, necessidade em projeto pequeno, falha do próprio balanceador e escolha entre camadas. Use-as como checklist mental antes de comprar ferramenta ou aceitar um desenho pronto de terceiros.

O que é balanceamento de carga em linguagem simples?#

É espalhar o trabalho de atender usuários entre vários servidores saudáveis, em vez de depender de uma máquina só. O balanceador fica na frente, escolhe o destino e tira do rodízio quem está doente. O ganho é mais fôlego sob pico e melhor chance de continuar no ar se um nó falhar, com o custo de operar mais partes móveis.

Balanceamento de carga e CDN são a mesma coisa?#

Não. A CDN distribui sobretudo conteúdo e pontos de presença perto do usuário, enquanto o balanceador de carga decide entre origens ou instâncias do seu serviço. Eles podem trabalhar juntos e o CERT.br cita ambos na preparação de resiliência, porém um não substitui o outro em todos os cenários. Avalie onde está o gargalo antes de contratar os dois.

Projeto pequeno precisa de load balancer?#

Nem sempre. Um site estático simples ou um MVP com tráfego baixo pode viver sem essa camada no começo. No entanto, quando houver requisito claro de continuidade, mais de uma instância ou pico previsível, o balanceador deixa de ser luxo e vira controle de risco. O ponto de virada é ter pelo menos duas cópias saudáveis do mesmo serviço e um modo de provar a falha de uma delas.

E se o próprio balanceador falhar?#

Aí ele vira ponto único de falha. Por isso desenhos maduros usam pares, zonas diferentes ou serviço gerenciado com redundância explícita. Sem isso, você só moveu o risco do servidor de aplicação para o ingresso. Teste a perda do nó de entrada com o mesmo rigor com que testa a perda de um backend.

Qual a diferença prática entre camada 4 e camada 7?#

Camada 4 encaminha com base em conexão e portas, com menos inspeção do conteúdo da aplicação. Camada 7 entende HTTP e permite regras por caminho, host ou cabeçalho, ao preço de mais configuração e responsabilidade sobre TLS e cabeçalhos. Escolha pela necessidade de roteamento inteligente, não pelo jargão do fornecedor.

Round-robin basta na maior parte dos casos?#

Basta como ponto de partida quando as instâncias são parecidas e o estado não mora na máquina. Deixa de bastar quando há clientes muito desiguais, sessões grudadas no servidor ou backends com capacidade diferente. Nesses casos, métrica de carga, pesos e afinidade entram na conversa, sempre com teste sob tráfego realista.

Conclusão#

Para a maioria dos times que expõe site ou API com mais de uma instância, balanceamento de carga deixa de ser detalhe e vira condição de operação segura sob variação de demanda. O caminho sensato é começar pelo contrato do serviço, subir pelo menos duas réplicas, configurar health check que meça a aplicação de verdade e ensaiar a morte de um nó.

A resposta muda quando o gargalo não está na camada que você está espalhando, quando a equipe não consegue operar a complexidade extra ou quando o tráfego ainda não justifica o custo. Nesses casos, corrija o gargalo, simplifique o estado e só então some o load balancer.

O primeiro passo objetivo é mapear o fluxo de uma requisição real do DNS até o banco, marcar onde há ponto único e decidir qual falha você precisa sobreviver no próximo trimestre. Sem esse mapa, qualquer ferramenta vira enfeite caro.

Este verbete sobre balanceamento de carga é informativo e geral. Não é projeto de arquitetura, consultoria de infraestrutura nem garantia de disponibilidade, desempenho ou proteção contra abuso. Ferramentas, nomes de serviço e práticas de nuvem mudam com frequência. Confira a documentação oficial do seu provedor na data da implementação e valide o desenho com testes de falha e de carga no seu próprio ambiente.