Como o API Gateway simplifica sua vida

Chega de refazer tudo do zero em cada microsserviço. Centraliza, organiza e segue o fluxo.

mai 28, 2025

Às vezes a gente se pega naquela situação clássica:
"Nossa, mais um microserviço pra implementar autenticação, logs e rate limiting... de novo!"

Pois é… dá pra simplificar isso.

Cada novo serviço acaba repetindo o mesmo código, as mesmas preocupações, os mesmos testes. E quando você precisa mudar a lógica de autenticação?
Tem que atualizar TODOS os serviços. Um pesadelo.

E não para por aí:
Quando o cliente reclama que a API está lenta, você fica perdido tentando descobrir onde está o gargalo, já que o monitoramento está espalhado por vários lugares.

É nesse momento que o API Gateway entra. Não como uma solução mágica — longe disso — mas como uma forma inteligente de centralizar preocupações comuns e deixar seus serviços focados no que realmente importa: as regras de negócio.

Antes de mais nada: o que é um API Gateway de verdade?

Muita gente ainda acha que API Gateway é só um proxy reverso glorificado ou mais uma camada de complexidade desnecessária.

Mas vamos lá:

“API Gateway é o porteiro do seu prédio de APIs.”

Assim como um porteiro controla quem entra, direciona pro apartamento certo e mantém um registro, o API Gateway:

Recebe todas as requisições externas
Autentica e autoriza os acessos
Direciona a chamada para o serviço correto
Monitora tráfego e performance

Na prática, ele fica entre seus clientes (apps, sites, outros sistemas) e seus serviços de backend, gerenciando tudo de forma centralizada.

Quando você REALMENTE precisa de um API Gateway?

Vou ser direta: nem todo projeto precisa.

Se você tem uma aplicação monolítica simples, com poucas integrações externas, provavelmente é exagero.

Mas...
Se você se identifica com algum desses cenários, vale prestar atenção:

Tem vários microserviços que precisam ser acessados por clientes externos
Tá cansado de reimplementar autenticação em todo lugar
Performance e monitoramento estão difíceis de rastrear
Precisa de controle granular sobre quem acessa o quê e com qual frequência.

No meu caso, o ponto de virada foi quando percebi que estava gastando mais tempo implementando funcionalidades periféricas (autenticação, logs, rate limiting) do que trabalhando no que realmente importa: as regras de negócio.
Foi aí que decidi centralizar tudo isso em um API Gateway.

Nunca mais olhei pra trás.

Funcionalidades que fazem toda diferença no dia a dia

Antes de sair instalando qualquer coisa, é importante entender o que um bom API Gateway precisa oferecer:

1. Roteamento e Proxy Reverso

Parece simples: receber requisições e encaminhar pro serviço certo.
Mas um bom API Gateway permite regras complexas de roteamento, com base em path, método HTTP, headers, e até no conteúdo da requisição.

Exemplo prático:
Você tem três serviços:

/users/* → Serviço de Usuários
/products/* → Serviço de Produtos
/orders/* → Serviço de Pedidos

Com um API Gateway, você configura essas rotas uma vez, e os clientes só precisam conhecer um único endpoint.

2. Autenticação e Autorização

Implementar segurança em cada serviço é cansativo e propenso a erros.
Um API Gateway centraliza isso.

Exemplo:
Configura autenticação JWT uma vez só.
Ele valida o token, verifica as permissões e só depois encaminha pro serviço interno, que já recebe tudo certinho.

3. Rate Limiting e Throttling

Pra proteger seus serviços de abusos e garantir que ninguém monopolize os recursos.

Exemplo:
Limite cada cliente a 100 requisições por minuto.
Se alguém ultrapassar, o gateway já devolve um 429 (Too Many Requests) sem nem sobrecarregar seus serviços.

4. Transformação de Requisições/Respostas

Às vezes o cliente manda um formato que seu serviço não quer receber.

Exemplo:
Um app mobile envia dados simplificados, e o gateway enriquece ou adapta a requisição antes de enviar pro backend.
Ou ainda: remove informações sensíveis da resposta antes de devolver ao cliente.

5. Monitoramento e Analytics

Ter visibilidade é essencial.

Exemplo:
Saber quais endpoints são mais acessados, quais estão lentos, quem são os principais consumidores...
Ou identificar padrões suspeitos que podem indicar problemas.

Te apresento: Kong API Gateway!

Depois de testar várias opções, escolhi o Kong para este tutorial por alguns motivos:

É open-source (tem versão Community gratuita)
Pode ser instalado localmente ou na nuvem
É altamente extensível através de plugins
Tem uma comunidade ativa
Funciona bem tanto com arquiteturas monolíticas quanto com microsserviços

Instalação

A maneira mais simples de começar, na minha opiniao, é usando Docker. Crie um arquivo docker-compose.yml:

version: '3'
services:
  kong-database:
    image: postgres:13
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kong
    volumes:
      - kong_data:/var/lib/postgresql/data

  kong-migrations:
    image: kong:latest
    depends_on:
      - kong-database
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong
    command: kong migrations bootstrap

  kong:
    image: kong:latest
    depends_on:
      - kong-migrations
      - kong-database
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
    ports:
      - "8000:8000"  # Porta para as APIs
      - "8001:8001"  # Porta de administração
    volumes:
      - kong_conf:/etc/kong

volumes:
  kong_data:
  kong_conf:

Depois é só:

docker-compose up -d

PS: Em produção, você vai precisar de configurações mais robustas de segurança, mas isso é suficiente para começar.

Configuração Básica

Depois de instalado, você pode acessar a interface em

http://localhost:8001

. Mas eu prefiro usar a API REST ou o formato declarativo YAML/JSON para configurações que possam ser versionadas.

1. Criando um Serviço

Um serviço no Kong representa seu backend API. Vamos criar um:

curl -i -X POST http://localhost:8001/services \
  --data name=example-service \
  --data url=http://mockbin.org

2. Adicionando uma Rota

Agora precisamos de uma rota que direcione o tráfego para esse serviço:

curl -i -X POST http://localhost:8001/services/example-service/routes \
  --data 'paths[]=/example' \
  --data name=example-route

E pronto! Agora você pode acessar http://localhost:8000/example e o kong te redirecionará para http://mockbin.org

Configuração Declarativa

Para projetos reais, prefiro usar o formato declarativo, que permite versionar a configuração:

Salve isso como kong.yml e aplique com:

curl -X POST http://localhost:8001/config \
  -F config=@kong.yml

Configurações que vão te salvar no dia a dia

Agora que temos o básico funcionando, vamos a algumas configurações mais avançadas que fazem toda a diferença:

1. Autenticação com Key Auth

Vamos proteger nossa API com uma simples autenticação por chave:

# Adicionar plugin de autenticação à rota
curl -X POST http://localhost:8001/routes/example-route/plugins \
  --data name=key-auth

# Criar um consumidor
curl -X POST http://localhost:8001/consumers \
  --data username=exemplo-app

# Gerar uma chave para o consumidor
curl -X POST http://localhost:8001/consumers/exemplo-app/key-auth \
  --data key=code-in-real-life

Agora, para acessar a API, é necessário incluir o header:

apikey: code-in-real-life

2. Rate Limiting

curl -X POST http://localhost:8001/routes/example-route/plugins \
  --data name=rate-limiting \
  --data config.minute=100 \
  --data config.policy=local

Isso limita cada cliente a 100 requisições por minuto.

3. Transformação de Resposta

Adicionando um header personalizado a todas as respostas:

curl -X POST http://localhost:8001/routes/example-route/plugins \
  --data name=response-transformer \
  --data config.add.headers=X-Powered-By:MeuAPIGateway

4. Monitoramento com Prometheus

Para ter métricas detalhadas:

curl -X POST http://localhost:8001/plugins \
  --data name=prometheus

Assim, você pode acessar http://localhost:8001/metrics e integrar com Grafana para visualizações mais consistentes.

Ok, e quando o API Gateway pode se tornar um problema?

Nem tudo são flores.
Um API Gateway pode, sim, virar um gargalo:

Latência adicional
Ponto único de falha
Mais complexidade operacional

Já vi sistemas onde o uso excessivo de API Gateway gerou latência absurda, principalmente quando mal configurado ou sem caching.
E pior: já vi o gateway cair e derrubar tudo.

Então, minha recomendação é:
Avalie o cenário.
Implemente boas práticas:

Clusters para alta disponibilidade;
Configure caching;
Monitore bem;
Mantenha a configuração simples e documentada.

API Gateway pode ser melhor do que refatorar tudo

A tentação de reescrever ou migrar pra uma nova stack é grande.
Mas a real é: muitas vezes o problema tá na arquitetura, não na tecnologia.

Implementar um API Gateway bem feito pode ser mais eficiente do que sair quebrando tudo.

No meu caso, consegui resolver problemas de performance, segurança e observabilidade sem tocar no código dos serviços.
Economizou meses de desenvolvimento — e, claro, evitou novos bugs.

Dicas extras

Se você quer se aprofundar em arquitetura de APIs, microsserviços e padrões de integração, recomendo bastante o livro Building Microservices do Sam Newman e o curso "API Design Patterns" da Pluralsight.

E se você já usa API Gateway nos seus projetos, compartilhe sua experiência nos comentários =)

Até o próximo post!

Code in Real Life

Discussão sobre este post

Pronto para mais?