System Design/02 - Componentes/Load Balancers2 min
Layer 7 Load Balancing
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Balanceamento na camada de aplicação. O balanceador termina a conexão, lê a requisição HTTP e decide o destino com base no conteúdo.
GET /api/pedidos → serviço-pedidos
GET /imagens/* → serviço-midia
Host: admin.app.com → serviço-admin
O que se torna possível
| Capacidade | Uso |
|---|---|
| Roteamento por path/host/header | Um domínio, vários serviços — base de Gateway Routing |
| Terminação TLS | Certificado centralizado (Gateway Offloading) |
| Health check real | GET /health e inspeção da resposta |
| Sticky session | Cookie de afinidade |
| Retry | Requisição falhou? Tenta outro backend |
| Compressão, cache, WAF | Preocupações transversais fora da aplicação |
| Canary / blue-green | Divisão de tráfego por peso |
Trade-offs
| Ganha | Perde |
|---|---|
| Roteamento inteligente | Latência maior (~milissegundos) |
| Health check confiável | Mais CPU (parse + TLS) |
| TLS e WAF centralizados | Só HTTP/HTTPS/gRPC |
| Balanceia por requisição | Termina a conexão fim a fim |
Balancear por requisição em vez de por conexão é uma vantagem real e frequentemente esquecida: com HTTP/2, um único cliente pode multiplexar mil requisições numa conexão, e apenas o L7 consegue distribuí-las.
O custo estrutural é que o balanceador vê o conteúdo — o que significa que a criptografia termina ali. Se o requisito é fim a fim até o backend, é preciso re-criptografar internamente, pagando o custo duas vezes.
L7 também vira ponto de concentração de lógica. Regras de roteamento acumuladas no balanceador viram configuração crítica que ninguém entende inteira — e um deploy de configuração passa a ser tão arriscado quanto um deploy de código.
Exemplo prático
Um domínio único, app.com, servindo quatro serviços:
/api/* → serviço-api (10 instâncias)
/static/* → CDN
/ws → serviço-realtime (sticky)
/* → frontend (4 instâncias)
Um só certificado TLS, um só ponto de entrada, um só lugar para aplicar rate limit e WAF. Os serviços internos falam HTTP simples e não sabem nada sobre TLS ou roteamento.
Para migrar o /api para uma versão nova, basta enviar 5% do tráfego para o novo grupo e observar. Nada disso seria possível em Layer 4 Load Balancing — o balanceador não saberia o que é /api.
Relacionado
Parte de Load Balancers · roadmap.sh/system-design