API gateway: quando vale a pena implementar

A venda do API gateway é sedutora: "centralize autenticação, rate limiting, logging, transformação de requests e roteamento em uma única camada. Seus serviços ficam livres dessas preocupações transversais." Para arquiteturas de microsserviços com dezenas de serviços, isso faz sentido. Para um monolito Next.js com três desenvolvedores, é overengineering puro.

O problema com API gateways não é que são ruins — é que são frequentemente adotados antes de o projeto ter o tamanho que justifica a complexidade. Este guia explica o que um API gateway faz bem, quando a complexidade se paga e quando você deveria resolver o problema de forma mais simples.

O Que um API Gateway Faz Bem

Um API gateway é um proxy reverso inteligente que fica entre os clientes e os seus serviços backend. Ele intercepta todas as requisições e pode executar lógica antes e depois de encaminhar para o serviço destino.

Funcionalidades centrais:

Autenticação e autorização centralizadas: Em vez de cada microsserviço validar JWT ou API keys, o gateway valida uma vez e encaminha a requisição com os claims do usuário já decodificados. Os serviços internos confiam no gateway e não precisam implementar autenticação individualmente.

Rate limiting por rota e por cliente: Configure limites diferentes para endpoints diferentes sem tocar no código dos serviços. /api/reports tem limite de 10 req/min. /api/health não tem limite. Cliente do plano free tem 1.000 req/dia. Cliente enterprise tem 100.000 req/dia.

Logging e observabilidade centralizados: Cada requisição passa pelo gateway, então você tem um ponto único para capturar latência, status codes, IPs de origem e payloads (quando necessário). Sem gateway, você precisa instrumentar cada serviço individualmente.

Roteamento e balanceamento de carga: Roteia /api/v1/orders para o serviço de pedidos, /api/v1/products para o serviço de produtos. Faz blue/green deployment ou canary releases controlando a porcentagem de tráfego para cada versão.

Transformação de requests/responses: Renomeia campos, converte formatos, adiciona headers. Útil para adaptar APIs legadas sem reescrevê-las.

Kong vs AWS API Gateway vs Traefik: Comparativo

Critério	Kong	AWS API Gateway	Traefik
Tipo	Self-hosted ou cloud	Managed (AWS)	Self-hosted
Configuração	Admin API / YAML	Console AWS / Terraform	YAML / Docker labels
Plugins	+100 plugins (auth, rate limit, logging)	Integrações AWS nativas	Middlewares extensíveis
Performance	Alta (Nginx-based)	Alta (gerenciado pela AWS)	Alta (Go)
Custo	Gratuito (OSS) / pago (Enterprise)	Pay-per-request (~$3.50/milhão)	Gratuito
Curva de aprendizado	Média-alta	Média	Baixa-média
Melhor para	Microsserviços multi-cloud	Aplicações AWS-native (Lambda, ECS)	Kubernetes / Docker Swarm

Kong é o líder open source em features. Com plugin deck para GitOps e suporte a múltiplos plugins de autenticação (JWT, OAuth2, LDAP, mTLS), é a escolha para equipes que precisam de controle total e não querem lock-in de cloud.

AWS API Gateway faz sentido quando você já está no ecossistema AWS — integra nativamente com Lambda, Cognito para autenticação, CloudWatch para logs e IAM para autorização. O modelo de cobrança por requisição pode ficar caro em alto volume, mas abaixo de ~10 milhões de requisições/mês o custo é razoável.

Traefik brilha em ambientes Kubernetes e Docker. A configuração automática via labels de container elimina muito do trabalho manual. Para times que já usam Kubernetes e querem um ingress controller com funcionalidades de gateway, Traefik é a escolha natural.

Quando Adiciona Complexidade Desnecessária

Esta é a parte que os tutoriais de API gateway costumam pular. Um API gateway adiciona:

Um hop de rede extra em cada requisição. Latência adicional de 5-15ms por request. Pequeno, mas real, e se acumula em APIs com muitas chamadas em série.

Um novo sistema para operar. Kong precisa de PostgreSQL ou Cassandra para estado. AWS API Gateway tem seu próprio modelo de configuração. Traefik precisa de configuração de ingress. Você precisa monitorar a saúde do gateway, fazer deploy de mudanças nele, depurar problemas nele.

Um novo ponto de falha. Se o gateway cai, toda a API fica indisponível. Você precisa de alta disponibilidade no gateway em si — o que em Kubernetes significa múltiplos pods, PodDisruptionBudget, readiness probes bem configuradas.

Configuração duplicada. Você configura autenticação no gateway E precisa que os serviços internos confiem nas identidades propagadas pelo gateway. Qualquer mudança na política de auth precisa ser sincronizada.

Quando o API gateway provavelmente não vale a pena:

• Monolito ou aplicação com 2-3 serviços
• Time com menos de 5 desenvolvedores
• Menos de 1 milhão de requisições/mês
• Sem múltiplos clientes consumindo a API (mobile + web + parceiros)
• Startup em fase de validação de produto

Para esses casos, middleware no próprio servidor HTTP (Express middleware, Next.js middleware) faz tudo que você precisa sem a complexidade operacional.

Implementando Rate Limiting e Auth no Gateway

Se você decidiu que um API gateway faz sentido, veja como configurar as funcionalidades mais comuns no Kong:

# kong.yaml — configuração declarativa (deck)
_format_version: "3.0"

services:
  - name: orders-service
    url: http://orders-service:3001
    routes:
      - name: orders-api
        paths:
          - /api/v1/orders
        methods:
          - GET
          - POST
          - PATCH
    plugins:
      # Autenticação via JWT
      - name: jwt
        config:
          key_claim_name: sub
          claims_to_verify:
            - exp
            - nbf

      # Rate limiting por consumidor
      - name: rate-limiting
        config:
          minute: 100
          hour: 2000
          policy: redis
          redis_host: redis
          redis_port: 6379

      # Logging estruturado
      - name: file-log
        config:
          path: /var/log/kong/access.log
          reopen: true

  - name: public-api
    url: http://public-service:3002
    routes:
      - name: public-routes
        paths:
          - /api/public
    plugins:
      # Rate limiting mais permissivo para endpoints públicos
      - name: rate-limiting
        config:
          minute: 30
          policy: ip

Para AWS API Gateway com Lambda authorizer:

// Lambda authorizer: valida JWT e retorna IAM policy
export const handler = async (event: APIGatewayAuthorizerEvent) => {
  const token = event.authorizationToken?.replace("Bearer ", "");

  try {
    const payload = await verifyJWT(token);
    return {
      principalId: payload.sub,
      policyDocument: {
        Version: "2012-10-17",
        Statement: [{
          Action: "execute-api:Invoke",
          Effect: "Allow",
          Resource: event.methodArn,
        }],
      },
      context: {
        userId: payload.sub,
        role: payload.role,
      },
    };
  } catch {
    throw new Error("Unauthorized");
  }
};

Conclusão

API gateway é uma ferramenta poderosa para o problema certo: múltiplos serviços, múltiplos clientes, políticas transversais que você quer gerenciar em um ponto central sem tocar em cada serviço.

Para a maioria dos projetos em crescimento, o caminho inteligente é começar sem gateway (middleware no servidor HTTP), definir interfaces limpas entre serviços e adicionar gateway quando a complexidade real justificar — não quando você imagina que vai precisar no futuro.

A decisão de adotar um API gateway é exatamente o tipo de escolha arquitetural que deveria ser documentada antes do desenvolvimento começar, com critérios claros de quando revisitar. No SystemForge, decisões como essa fazem parte do HLD e do ADR do projeto — registradas com contexto, alternativas consideradas e critérios de reavaliação. Isso evita tanto o overengineering prematuro quanto a ausência de estrutura quando o sistema cresce. Se você está desenhando a arquitetura de uma API, podemos ajudar a tomar essas decisões com base no seu contexto real.