System Design/02 - Componentes/Load Balancers2 min
LB vs Reverse Proxy
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Os dois ficam na frente dos servidores e são frequentemente o mesmo software (nginx, HAProxy, Envoy) — mas resolvem problemas diferentes.
| Load Balancer | Reverse Proxy | |
|---|---|---|
| Propósito | Distribuir carga entre N backends | Intermediar o acesso ao backend |
| Faz sentido com 1 backend? | Não | Sim |
| Preocupação central | Capacidade e disponibilidade | Segurança, cache, TLS, roteamento |
Um proxy reverso com vários backends é um load balancer. Um load balancer que termina TLS e cacheia é um proxy reverso. Na prática, todo produto moderno faz as duas coisas.
Forward proxy vs reverse proxy
A distinção que realmente importa é outra:
| Forward proxy | Reverse proxy | |
|---|---|---|
| Fica na frente do | Cliente | Servidor |
| Esconde | Quem é o cliente | Qual servidor atendeu |
| Quem configura | O cliente | O dono do servidor |
| Exemplo | Proxy corporativo, VPN | nginx, CloudFront, ALB |
Trade-offs
O que um proxy reverso agrega, mesmo com um único backend: terminação TLS, compressão, cache, servir arquivo estático sem tocar a aplicação, rate limit, WAF, reescrita de URL, e esconder a topologia interna.
O custo é ser mais um salto na rede e mais um ponto único de falha — que precisa da própria redundância. E é onde configuração crítica se acumula: regras de roteamento no proxy viram, com o tempo, um sistema que ninguém entende inteiro e cujo deploy é tão arriscado quanto o da aplicação.
Uma consequência prática frequentemente esquecida: como o backend passa a ver o IP do proxy, e não o do cliente, é preciso propagar X-Forwarded-For — e confiar nele apenas quando vem do próprio proxy, senão vira vetor de falsificação.
Exemplo prático
Uma aplicação Node.js com uma instância só, atrás de nginx.
Não há balanceamento — há um proxy reverso fazendo: TLS com o certificado, gzip nas respostas, servindo /static direto do disco sem acordar o Node, limitando requisições por IP, e escondendo que o backend é Node na porta 3000.
Quando o tráfego crescer e a segunda instância subir, o mesmo nginx vira também load balancer com uma linha de configuração. É o mesmo componente assumindo o segundo papel.
Relacionado
Parte de Load Balancers · roadmap.sh/system-design