Construindo API Gateways para Microsserviços: Roteamento, Autenticação, Rate Limiting e Resiliência

1. Introdução: Por Que Toda Arquitetura de Microsserviços Exige um API Gateway

Em sistemas distribuídos modernos, permitir que clientes externos (aplicações web, aplicativos móveis ou integrações de terceiros) se comuniquem diretamente com dezenas de microsserviços internos representa um grave anti-pattern arquitetural.

O modelo de conexão direta acarreta sérios riscos operacionais:

• Acoplamento excessivo: Qualquer divisão, renomeação ou alteração de rotas exige o lançamento forçado de atualizações para todos os aplicativos clientes.
• Superfície de ataque expandida: Expor cada serviço diretamente à Internet pública fragmenta as regras de firewall, configurações de CORS e certificados TLS.
• Duplicação de regras transversais: Cada time acaba desenvolvendo sua própria lógica de validação de JWT e rate limiting, gerando inconsistências e brechas de segurança.
• Latência excessiva de rede: Clientes móveis precisam disparar mais de dez requisições HTTP em série para compor uma única tela.

Comunicação Direta vs Padrão API Gateway
=========================================
Acesso Direto (Anti-pattern):
[App Mobile] ──┬──► [Serviço Autenticação :8081]
               ├──► [Serviço Pedidos :8082]
               ├──► [Serviço Pagamentos :8083]
               └──► [Serviço Estoque :8084]

Padrão API Gateway (Recomendado):
               ┌────────────────────────────────────────────────────────┐
               │                 API Gateway (:443)                     │
               │  - Terminação SSL & Políticas de CORS                  │
               │  - Validação Criptográfica de JWT & Propagação         │
               │  - Rate Limiting Distribuído com Redis (Token Bucket)  │
               │  - Roteamento Inteligente, Timeouts e Circuit Breaker  │
               └──────────────────────────┬─────────────────────────────┘
                                          │ Rede Privada VPC (mTLS)
                     ┌────────────────────┼────────────────────┐
                     ▼                    ▼                    ▼
             [Serviço Auth]       [Serviço Pedidos]    [Serviço Pagamentos]

O API Gateway atua como um ponto único de entrada (proxy reverso) na fronteira do sistema, centralizando todas as preocupações transversais.

2. Camadas Funcionais Essenciais do Gateway Corporativo

Um API Gateway pronto para produção deve executar com confiabilidade e latência inferior a um milissegundo as seguintes funções:

3. Autenticação e Defesa em Profundidade (Defense in Depth)

Princípio Inegociável: A Autenticação no Gateway Não Substitui a Autorização no Microsserviço

Muitas equipes assumem erroneamente que, «uma vez que o token foi validado pelo API Gateway, os microsserviços internos não precisam se preocupar com permissões».

Se o gateway for comprometido ou se uma chamada interna for forjada na rede privada, os serviços downstream ficam desprotegidos. O modelo de Defesa em Profundidade é indispensável:

Fluxo de Defesa em Profundidade
-------------------------------
[Cliente]
   │ 1. Authorization: Bearer <JWT>
   ▼
[API Gateway]
   │ 2. Valida a assinatura do JWT contra o conjunto de chaves públicas JWKS em cache
   │ 3. Valida prazos (exp) e emissor (iss); rejeita requisições forjadas com 401
   │ 4. Converte claims validados em cabeçalhos internos confiáveis:
   │    - X-User-Id: 98412
   │    - X-User-Roles: billing_admin,user
   │    - X-Tenant-Id: tenant_corp_a
   ▼
[Microsserviço Downstream (Pedidos/Pagamentos)]
   │ 5. Confirma conexão mTLS segura originada pelo gateway
   │ 6. Avalia no contexto local se as roles de X-User-Roles têm permissão para a operação
   │ 7. Executa a lógica de negócios

4. Rate Limiting Distribuído: Algoritmo Token Bucket no Redis

Contadores locais em memória falham completamente em ambientes orquestrados que escalam horizontalmente (HPA). Se a quantidade de pods do gateway sobe de 2 para 20, o limite concedido aos clientes se multiplica por dez.

Com um cluster Redis e scripts Lua atômicos, obtém-se controle exato e nanosegundo sobre os limites:

-- Redis Token Bucket Rate Limiting (Script Lua Atômico)
-- KEYS[1]: Chave de limitação (ex: ratelimit:tenant_123:orders)
-- ARGV[1]: Capacidade máxima do balde (Burst)
-- ARGV[2]: Taxa de reposição de tokens (Tokens / Segundo)
-- ARGV[3]: Timestamp Unix atual (segundos)
-- ARGV[4]: Tokens solicitados nesta requisição (normalmente 1)

local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local fill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local data = redis.call('HMGET', key, 'tokens', 'last_updated')
local tokens = tonumber(data[1])
local last_updated = tonumber(data[2])

if not tokens then
    tokens = capacity
    last_updated = now
else
    local elapsed = math.max(0, now - last_updated)
    tokens = math.min(capacity, tokens + (elapsed * fill_rate))
    last_updated = now
end

if tokens >= requested then
    tokens = tokens - requested
    redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
    redis.call('EXPIRE', key, math.ceil(capacity / fill_rate) * 2)
    return {1, math.floor(tokens)} -- 1 = Permitido
else
    redis.call('HMSET', key, 'tokens', tokens, 'last_updated', last_updated)
    return {0, 0} -- 0 = Rejeitado (429 Too Many Requests)
end

5. Padrões de Resiliência: Timeouts, Retries e Circuit Breakers

1. Timeouts Precisos: O tempo limite de espera no gateway deve ser estritamente menor do que o timeout interno do microsserviço para evitar o travamento de conexões.
2. Retries Idempotentes: Apenas requisições idempotentes (GET, PUT, DELETE) podem ser reenviadas automaticamente. Tentar reenviar um POST de pagamento cria cobranças duplicadas.
3. Circuit Breakers: Quando um microsserviço responde com mais de 50% de erros 5xx, o circuito abre (OPEN), falhando imediatamente e retornando uma resposta de contingência.

6. Comparativo de Tecnologias: Envoy vs NGINX vs Kong

7. API Gateway vs Service Mesh

• API Gateway (Tráfego Norte-Sul): Controla o tráfego que cruza a fronteira da Internet pública para a infraestrutura privada (autenticação de clientes, faturamento, cotas e contratos de API).
• Service Mesh (Tráfego Leste-Oeste): Governa a comunicação interna de serviço a serviço (Istio, Linkerd), viabilizando criptografia mTLS ponta a ponta e roteamento canário fino.