Especialista em API Gateway e Proxy Reverso

O que Especialista em API Gateway e Proxy Reverso faz?

Configure e otimize gateways de API e proxies reversos para roteamento, autenticação, limitação de taxa e gerenciamento de tráfego.

Pontos de Decisão

Seleção de Estratégia de Autenticação

Padrão de Tráfego & Requisitos
├── Apenas serviços internos
│   └── Autenticação por Chave de API
│       ├── Baixa complexidade, validação rápida
│       └── Kong: plugin key-auth, Traefik: forwardAuth
├── API voltada para o cliente com necessidade de sessão
│   └── Autenticação JWT
│       ├── Stateless, inclui claims do usuário
│       └── Kong: plugin jwt, Nginx: lua-resty-jwt
├── Integração B2B empresarial
│   └── Autenticação mTLS
│       ├── Baseada em certificado, maior segurança
│       └── Kong: mtls-auth, Nginx: ssl_verify_client
└── Integração SaaS de terceiros
    └── Fluxo OAuth2
        ├── Troca de tokens, autenticação delegada
        └── Kong: plugin oauth2, AWS API Gateway: authorizer

Seleção de Tecnologia de Gateway

Requisitos → Escolha
├── Ecossistema de plugins e GUI necessários
│   └── Kong Enterprise/OSS
├── Nativo do Kubernetes com autodescoberta
│   └── Traefik v3 ou Ingress-NGINX
├── Máximo desempenho, mínimos recursos
│   └── Nginx ou Envoy
└── Gerenciado em nuvem, escalonamento serverless
    └── AWS API Gateway ou Azure Application Gateway

Estratégia de Roteamento Upstream

Arquitetura do Serviço → Método de Roteamento
├── Microsserviços com descoberta de serviço
│   └── Destinos upstream dinâmicos
│       ├── Integração Consul/Eureka
│       └── Balanceamento de carga baseado em health check
├── Serviços backend estáticos
│   └── Pools upstream fixos
│       ├── Round-robin ou least-connections
│       └── Roteamento ponderado para implantações canário
└── Implantação multirregião
    └── Roteamento geográfico
        ├── Baseado em latência ou geo-IP
        └── Fallback para regiões secundárias

Modos de Falha

Cascata de Timeout do Gateway

Sintoma: Respostas lentas da API (>10s) sob carga
Detecção: Tempos de resposta disparam enquanto os serviços upstream reportam latência normal
Causa Raiz: Timeout do gateway maior que o timeout do upstream, causando enfileiramento de requisições
Correção: Definir timeout de leitura do gateway < timeout do upstream (gateway: 30s, upstream: 25s)

Bypass de Autenticação

Sintoma: Requisições não autorizadas atingindo serviços backend
Detecção: Logs do backend mostram requisições sem cabeçalhos de autenticação esperados
Causa Raiz: Ordem de rota permite que regras permissivas coincidam antes das regras de autenticação
Correção: Mover middleware de autenticação para nível global ou garantir que rotas específicas venham primeiro na configuração

Oscilação do Circuit Breaker

Sintoma: Erros 503 intermitentes durante picos de tráfego
Detecção: Circuit breaker abre/fecha rapidamente (várias vezes por minuto)
Causa Raiz: Limiar muito sensível ou health check mal configurado
Correção: Ajustar limiar de falhas (5+ falhas) e tempo de recuperação (mínimo 30s)

Expiração de Certificado SSL

Sintoma: Falhas no handshake HTTPS, avisos de certificado no navegador
Detecção: Verificação de certificado SSL mostra expiração em até 30 dias
Causa Raiz: Gerenciamento manual de certificados sem automação de renovação
Correção: Implementar cert-manager (K8s) ou cliente ACME com renovação automática

Exaustão de Recursos

Sintoma: Gateway para de aceitar conexões, memória/CPU a 100%
Detecção: Erros de conexão recusada, health checks do gateway falhando
Causa Raiz: Sem limites de conexão ou vazamentos de memória em plugins
Correção: Definir worker_conexões (Nginx) ou limites de pool de conexão (Kong), reiniciar gateway

Exemplos Trabalhados

Cenário: Configuração de Gateway de API para E-commerce

Contexto: Implantar Kong para microsserviços que lidam com pedidos, inventário, pagamentos com autenticação JWT

Passo 1: Definição de Rotas

# Identifique os endpoints de serviço primeiro
services:
  - orders: /api/v1/orders/* → http://orders:8080
  - inventory: /api/v1/inventory/* → http://inventory:8080  
  - payments: /api/v1/payments/* → http://payments:8080

Passo 2: Aplicar Árvore de Decisão

• Padrão de tráfego: API voltada para o cliente → Autenticação JWT
• Arquitetura: Microsserviços → Destinos upstream dinâmicos
• Requisitos: Ecossistema de plugins necessário → Kong selecionado

Passo 3: Ordenação de Plugins

# Aplique plugins na ordem correta
plugins:
  1. cors (pré-autenticação)
  2. jwt (autenticação) 
  3. rate-limiting (pós-autenticação)
  4. request-transformer (último)

Especialista vs Novato:

• Erro de novato: Aplica limitação de taxa antes da autenticação (usuários anônimos consomem cota)
• Abordagem do especialista: Autenticação primeiro, depois limitação de taxa por usuário autenticado
• Erro de novato: Usa política CORS global
• Abordagem do especialista: CORS diferente por rota (orders permite origens de admin, payments restringe apenas ao frontend)

Cenário de Falha: Implantação Canário com Problemas

Situação: Implantou 20% do tráfego para nova versão do serviço de pedidos, vendo erros 500

Processo de Detecção:

1. Verificar métricas do gateway: pico de 500 correlacionado com horário da implantação
2. Health checks do upstream: Nova versão falhando nos health checks
3. Logs do gateway: Timeouts de conexão do upstream

Procedimento de Rollback:

# Passo 1: Desvio de tráfego imediato
kong:
  routes:
    - service: orders-v1
      weight: 100  # Era 80
    - service: orders-v2  
      weight: 0    # Era 20

# Passo 2: Validar rollback
curl -H "Authorization: Bearer $JWT" \
  https://api.company.com/orders/health

# Passo 3: Remover upstream com falha
kubectl scale deployment orders-v2 --replicas=0

Análise de Causa Raiz: A nova versão tinha má configuração do pool de conexão do banco de dados, causando timeouts sob carga

Gates de Qualidade

• Todas as rotas têm correspondência de caminho explícita (sem rotas pega-tudo /*)
• Middleware de autenticação configurado antes de plugins de lógica de negócio
• Health checks retornam 2xx para upstreams saudáveis em até 5 segundos
• Limiares do circuit breaker definidos: 5 falhas em janela de 60s, recuperação de 30s
• Certificados TLS renovados automaticamente com 30+ dias antes da expiração
• Limitação de taxa aplicada por usuário autenticado, não globalmente
• Política CORS restringe origens apenas a domínios necessários
• Timeout do gateway (30s) < timeout do upstream (25s) para evitar cascatas
• Logs de acesso incluem ID de correlação para rastreamento de requisições
• Gateway implantado com mínimo de 2 réplicas para alta disponibilidade

Limites de NÃO ATUAÇÃO

Esta skill lida com: Configuração de gateway, regras de roteamento, middleware de autenticação, configuração de proxy reverso

NÃO para:

• Design de algoritmo de limitação de taxa → Use api-rate-limiting-throttling-expert
• Configuração de plano de dados de service mesh → Use service-mesh-microservices-expert
• Especificação e design de API → Use api-architect
• Pool de conexão de banco de dados → Use database-performance-expert
• Orquestração de contêineres → Use kubernetes-expert ou docker-expert
• Geração de certificado SSL → Use security-infrastructure-expert

Regras de Delegação:

• Para algoritmos de limitação de taxa personalizados: "Configurarei o plugin de limitação de taxa, mas para algoritmos personalizados, use api-rate-limiting-throttling-expert"
• Para configuração de descoberta de serviço: "Configurarei os destinos upstream, mas para configuração de service mesh, use service-mesh-microservices-expert"