API Gateway vs Load Balancer: quando usar cada um

1. Fundamentos e Definições

Um Load Balancer é um dispositivo ou software que distribui o tráfego de rede entre múltiplos servidores backend. Ele opera principalmente nas camadas 4 (transporte) e 7 (aplicação) do modelo OSI, garantindo que nenhum servidor fique sobrecarregado enquanto outros ficam ociosos.

Um API Gateway é um ponto único de entrada para sistemas distribuídos, especialmente arquiteturas de microsserviços. Ele gerencia requisições de API de forma inteligente, aplicando lógica de aplicação como autenticação, rate limiting e transformação de dados.

A diferença conceitual fundamental está na profundidade de processamento: enquanto o load balancer foca em distribuição eficiente de tráfego, o API gateway opera como um "cérebro" que entende e manipula o conteúdo das requisições.

2. Principais Funcionalidades do Load Balancer

Balanceamento de Carga

O load balancer implementa algoritmos como:

Round-robin: Distribui requisições sequencialmente entre servidores.

Servidor A -> Servidor B -> Servidor C -> Servidor A -> ...

Least connections: Envia tráfego para o servidor com menos conexões ativas.

IP hash: Garante que um mesmo cliente sempre seja direcionado ao mesmo servidor.

Health Checks e Failover

O load balancer monitora servidores periodicamente:

Health check: GET /health
Resposta esperada: 200 OK
Se falhar 3 vezes consecutivas: servidor removido do pool

Terminação SSL

Descarrega o processamento criptográfico dos servidores backend, melhorando performance.

3. Principais Funcionalidades do API Gateway

Roteamento Inteligente

O API Gateway pode rotear baseado em múltiplos critérios:

GET /api/v1/users -> microsserviço de usuários
GET /api/v1/orders -> microsserviço de pedidos
POST /api/v1/payments -> microsserviço de pagamentos (requer autenticação)

Rate Limiting e Autenticação

Políticas centralizadas de segurança:

Limite: 100 requisições/minuto por cliente
Autenticação: JWT ou OAuth 2.0
Validação: API Key no cabeçalho X-API-Key

Transformação de Dados

Agregação e modificação de respostas:

Requisição original: GET /user/123
Gateway transforma para:
  GET /user-service/users/123
  GET /order-service/orders?userId=123
  GET /payment-service/payments?userId=123
Resposta agregada: { usuario, pedidos, pagamentos }

4. Quando Priorizar o Load Balancer

Cenário 1: Aplicação Monolítica Escalada Horizontalmente

Arquitetura:
  Cliente -> Load Balancer (HAProxy) -> [App Server 1, App Server 2, App Server 3]

Requisitos:
  - 10.000 requisições/segundo
  - Latência máxima: 10ms
  - Sem lógica de aplicação no ponto de entrada

Cenário 2: Tráfego TCP/UDP Puro

Load Balancer (L4) distribuindo conexões de banco de dados:
  Cliente -> Load Balancer (L4) -> [MySQL Master, MySQL Slave 1, MySQL Slave 2]

Cenário 3: Alta Performance com Mínima Latência

Use load balancer quando a latência adicional de 1-2ms do API Gateway for inaceitável para seu caso de uso.

5. Quando Priorizar o API Gateway

Cenário 1: Arquitetura de Microsserviços

API Gateway (Kong) -> 
  /users -> User Service
  /orders -> Order Service  
  /inventory -> Inventory Service
  /notifications -> Notification Service

Benefícios:
  - Cliente faz uma requisição em vez de múltiplas
  - Segurança centralizada
  - Versionamento de APIs (/v1/, /v2/)

Cenário 2: Segurança Centralizada

API Gateway valida:
  1. Token JWT
  2. Permissões do usuário
  3. Rate limit por cliente
  4. Validação de payload (JSON Schema)

Se alguma validação falhar: retorna 401/403/429

Cenário 3: Políticas de Uso e Documentação

O API Gateway pode expor documentação OpenAPI/Swagger automaticamente e gerenciar versões de API sem afetar clientes existentes.

6. Cenários Híbridos: Usando Ambos

Arquitetura Recomendada para Produção

Internet
    |
AWS CloudFront (CDN)
    |
AWS ALB (Load Balancer L7)
    |
Amazon API Gateway
    |
[Auth Service, User Service, Order Service, Payment Service]

Exemplo Prático: AWS ALB + Amazon API Gateway

O ALB gerencia tráfego externo e terminação SSL, enquanto o API Gateway faz roteamento inteligente e segurança:

ALB configuração:
  - Listener: HTTPS (443)
  - Target group: API Gateway (HTTP)

API Gateway configuração:
  - Rate limit: 1000 req/s
  - Autenticação: Cognito User Pools
  - Roteamento: baseado em path (/users, /orders)

Estratégia de Failover Combinada

Se API Gateway falhar:
  Load Balancer redireciona para API Gateway secundário em outra região

Se microsserviço falhar:
  API Gateway retorna 503 ou fallback com dados em cache

7. Comparação Técnica e Performance

Característica Load Balancer API Gateway
Latência adicional 0.1-0.5ms 1-5ms
Camada de operação L4/L7 L7 (aplicação)
Processamento Binário/pacotes JSON/XML/texto
Consumo de recursos Baixo Médio/Alto
Complexidade Baixa Média/Alta

Ferramentas Populares:

Load Balancers: Nginx, HAProxy, AWS ALB/NLB, Google Cloud Load Balancing

API Gateways: Kong, KrakenD, AWS API Gateway, Azure API Management, Apigee

8. Guia de Decisão e Melhores Práticas

Checklist para Escolha

Use Load Balancer quando:
- [ ] Aplicação monolítica com múltiplas instâncias
- [ ] Tráfego puro de rede (TCP/UDP)
- [ ] Latência ultra-baixa é requisito crítico
- [ ] Sem necessidade de lógica de aplicação no ponto de entrada

Use API Gateway quando:
- [ ] Arquitetura de microsserviços
- [ ] Necessidade de autenticação/autorização centralizada
- [ ] Rate limiting e throttling são requisitos
- [ ] Transformação ou agregação de dados necessária

Use Ambos quando:
- [ ] Precisa de alta disponibilidade + lógica de aplicação
- [ ] Ambientes multi-região com failover
- [ ] Segurança em múltiplas camadas (defense in depth)

Exemplo de Arquitetura Final

Decisão documentada para Sistema de E-commerce:
1. CloudFront (CDN) para conteúdo estático
2. AWS ALB para distribuição de tráfego entre regiões
3. Kong API Gateway para roteamento de microsserviços
4. Rate limiting: 100 req/s por cliente
5. Autenticação: JWT validado no gateway
6. Health checks a cada 10 segundos

Armadilhas Comuns

  1. Não usar API Gateway em microsserviços: Cada serviço expõe portas diferentes, aumentando complexidade do cliente
  2. Usar API Gateway para tráfego puro: Adiciona latência desnecessária
  3. Ignorar health checks: Serviços falhos continuam recebendo tráfego
  4. Rate limiting muito agressivo: Bloqueia usuários legítimos
  5. SSL termination no gateway sem segurança: Tráfego interno não criptografado

Referências