API Gateway

Como centralizar o acesso aos seus microsserviços com um ponto de entrada único que gerencia roteamento, autenticação, rate limiting e transformação de respostas.

Que problema resolve

Em uma arquitetura de microsserviços, os clientes (web, mobile, IoT) precisam se comunicar com múltiplos serviços de backend. Sem um ponto de entrada centralizado, cada cliente precisa:

Conhecer os endereços de todos os serviços
Lidar com a autenticação de cada serviço individualmente
Lidar com protocolos e formatos de resposta diferentes
Implementar lógica de retentativas, timeouts e circuit breaking por conta própria

Sin API Gateway:
  Mobile App → Servicio Usuarios (auth + datos)
  Mobile App → Servicio Productos (auth + datos)
  Mobile App → Servicio Pedidos (auth + datos)
  Mobile App → Servicio Pagos (auth + datos)
  
  Cada cliente conoce N servicios
  Cada servicio implementa auth, rate limiting, CORS...

Isso gera acoplamento direto entre clientes e serviços internos, dificulta a evolução independente dos serviços e duplica preocupações transversais (cross-cutting concerns) em cada microsserviço.

Como funciona

O API Gateway atua como um proxy reverso que fica entre os clientes e os microsserviços. Todas as requisições externas passam por ele, e o gateway se encarrega de roteá-las para o serviço correto.

Con API Gateway:
  Mobile App  ─┐
  Web App     ─┤──► API Gateway ──► Servicio Usuarios
  IoT Device  ─┘         │──► Servicio Productos
                          │──► Servicio Pedidos
                          └──► Servicio Pagos
  
  Un solo punto de entrada
  Cross-cutting concerns centralizados

Responsabilidades principais

Responsabilidade	Descrição	Exemplo
Roteamento	Direcionar requisições ao serviço correto	`GET /api/users → User Service`
Autenticação	Validar tokens/credenciais antes de encaminhar	Verificar JWT em cada request
Rate Limiting	Limitar requisições por cliente/IP	100 requests/minuto por API key
Transformação	Adaptar request/response entre cliente e serviço	Adicionar campos, mudar formato
Agregação	Combinar respostas de múltiplos serviços	Dashboard com dados de 3 serviços
Cache	Cachear respostas frequentes	Catálogo de produtos por 5 min
Logging/Métricas	Registrar todas as requisições de forma centralizada	Latência, erros, throughput
CORS	Gerenciar políticas de origem cruzada	Permitir domínios específicos

Fluxo típico de uma requisição

1. Cliente envía: GET /api/products/123
2. Gateway recibe la solicitud
3. Gateway valida el token JWT → ✅ válido
4. Gateway verifica rate limit → ✅ dentro del límite
5. Gateway enruta a Product Service: GET /products/123
6. Product Service responde con datos del producto
7. Gateway transforma la respuesta (si es necesario)
8. Gateway registra métricas (latencia, status code)
9. Gateway devuelve respuesta al cliente

Padrões de composição

O API Gateway pode implementar diferentes estratégias de composição:

Request routing simples: Cada rota do gateway mapeia para um serviço específico.

/api/users/*     → User Service
/api/products/*  → Product Service
/api/orders/*    → Order Service

Agregação de respostas: O gateway chama múltiplos serviços e combina as respostas.

GET /api/dashboard
  → User Service: datos del usuario
  → Order Service: últimos pedidos
  → Product Service: recomendaciones
  ← Respuesta combinada al cliente

Vantagens

Desacoplamento: Os clientes não conhecem a topologia interna dos serviços
Cross-cutting concerns centralizados: Auth, rate limiting e logging são implementados uma única vez
Evolução independente: Você pode reorganizar os serviços internos sem afetar os clientes
Simplificação do cliente: Uma única URL, um único formato de autenticação
Observabilidade: Ponto central para métricas, logs e traces de todas as requisições
Segurança: Os serviços internos não ficam expostos diretamente à internet

Trade-offs / Desvantagens

Ponto único de falha: Se o gateway cair, todo o sistema fica inacessível (exige alta disponibilidade)
Latência adicional: Cada requisição tem um salto de rede extra
Complexidade operacional: O gateway precisa do próprio deployment, monitoramento e escalonamento
Gargalo: Todo o tráfego passa por um único componente (exige escalonamento horizontal)
Risco de lógica de negócio: É tentador adicionar lógica de negócio no gateway, o que é um antipadrão
Acoplamento ao gateway: Trocar a tecnologia de gateway pode ser custoso

Quando usar

Arquiteturas de microsserviços com múltiplos clientes (web, mobile, IoT)
Quando você precisa centralizar autenticação e autorização
Quando os clientes precisam de dados agregados de múltiplos serviços
Sistemas com requisitos de rate limiting e throttling
Quando você quer ocultar a complexidade interna dos serviços dos consumidores externos

Quando evitar

Aplicações monolíticas onde não há múltiplos serviços de backend
Sistemas internos onde os serviços se comunicam diretamente entre si (service-to-service)
Protótipos ou MVPs onde a complexidade adicional não se justifica
Quando a latência adicional de um salto extra é inaceitável

Tecnologias e implementações comuns

Categoria	Opções
Cloud-managed	AWS API Gateway, Azure API Management, Google Cloud Endpoints
Open source	Kong, Traefik, APISIX, Tyk
Service mesh	Istio Gateway, Envoy
Frameworks	Spring Cloud Gateway (Java), Ocelot (.NET), Express Gateway (Node.js)

Relação com outros padrões

BFF (Backend for Frontend): Variante do API Gateway especializada por tipo de cliente
Circuit Breaker: O gateway pode implementar circuit breaking em direção aos serviços downstream
Rate Limiting: Funcionalidade nativa do gateway para proteger os serviços
Service Discovery: O gateway precisa saber onde estão os serviços (Consul, Eureka, DNS)

Próximos passos

O API Gateway é o ponto de entrada da sua arquitetura. Para especializá-lo por tipo de cliente, explore o padrão BFF (Backend for Frontend). Para proteger os serviços downstream de falhas em cascata, revise o Circuit Breaker.