Introdução
Em arquiteturas modernas — especialmente microservices — é comum que um único produto seja composto por vários serviços pequenos, cada um com sua própria API. Isso traz benefícios como evolução independente e escalabilidade, mas também cria um problema prático: como clientes (web, mobile, parceiros) acessam tudo isso de forma simples, segura e consistente?
Se cada cliente falar diretamente com dezenas de serviços, surgem desafios de roteamento, segurança, versionamento, observabilidade e latência. É aí que entra o API Gateway: um componente que atua como “porta de entrada” para as APIs do backend.
Neste artigo, você vai entender o que é um API Gateway, quais problemas ele resolve, exemplos práticos e recomendações para uso no mundo real.
Desenvolvimento
1) O que é um API Gateway?
O API Gateway é um serviço intermediário que recebe as requisições dos clientes e as encaminha para os serviços internos apropriados. Em geral, o cliente conversa com um único endpoint (o gateway), e o gateway faz o trabalho de:
-
Roteamento (encaminhar
/orderspara o serviço de pedidos, por exemplo) - Autenticação e autorização (validar JWT/OAuth2, checar escopos)
- Rate limiting (limitar requisições por IP/usuário/chave)
- TLS termination (encerrar HTTPS no gateway e falar internamente na rede privada)
- Observabilidade (logs, métricas, tracing distribuído)
- Transformação de requisições/respostas (headers, formatos)
- Agregação (chamar múltiplos serviços e montar uma única resposta)
Na prática, ele centraliza preocupações transversais (“cross-cutting concerns”) que, se repetidas em cada microserviço, geram inconsistência e retrabalho.
2) Problema real: clientes falando com microservices diretamente
Imagine um app de e-commerce:
- Serviço de Catálogo
- Serviço de Carrinho
- Serviço de Pedidos
- Serviço de Pagamentos
- Serviço de Usuários
- Serviço de Entrega
Sem gateway, o app mobile poderia precisar:
- Fazer várias chamadas para montar a tela inicial
- Descobrir endpoints diferentes por ambiente (dev/hml/prod)
- Implementar autenticação e retentativas de formas diferentes
- Lidar com mudanças de API em múltiplos serviços
Isso aumenta:
- Acoplamento do cliente ao backend
- Complexidade de manutenção
- Superfície de ataque (mais serviços expostos publicamente)
- Dificuldade de governança (padrões e políticas)
3) Como o API Gateway resolve isso
a) Um único ponto de entrada (com roteamento)
Exemplo conceitual de rotas:
-
GET /api/products→ Catalog Service -
POST /api/orders→ Orders Service -
POST /api/payments→ Payments Service
O cliente só conhece o domínio do gateway, e o backend pode mudar internamente sem quebrar o app.
b) Segurança e controle centralizados
O gateway pode validar um JWT e repassar ao microserviço apenas claims necessárias (ou até trocar por credenciais internas). Isso padroniza:
- autenticação (OAuth2/OIDC)
- autorização (RBAC/ABAC/escopos)
- proteção contra abuso (rate limiting, quotas)
c) Observabilidade
Com gateway, fica mais fácil garantir que cada requisição tenha:
correlation-id- logs consistentes
- métricas por rota/cliente
- integração com tracing (ex.: OpenTelemetry)
d) Backend for Frontend (BFF)
Um padrão comum é ter um gateway por tipo de cliente:
- BFF Web
- BFF Mobile
- BFF Parceiros
Isso permite respostas “sob medida” (evita overfetch/underfetch), reduzindo chamadas e melhorando performance percebida.
4) Exemplos práticos (cenários comuns)
Exemplo 1: agregação para reduzir chamadas no mobile
Tela “Meus pedidos” pode precisar:
- pedidos
- status de entrega
- detalhes de pagamento
O gateway (ou BFF) pode chamar três serviços e devolver um JSON único, reduzindo latência e simplificando o app.
Exemplo 2: versionamento e compatibilidade
Você pode expor:
/v1/orders/v2/orders
Enquanto internamente a arquitetura evolui. O gateway ajuda a manter compatibilidade durante migrações.
Exemplo 3: políticas corporativas
Empresas frequentemente exigem:
- bloqueio por geolocalização
- WAF/anti-bot
- auditoria e logs de acesso
O gateway é um lugar natural para aplicar essas políticas.
5) Cuidados e trade-offs (quando evitar ou como mitigar)
API Gateway não é “mágica”; ele traz riscos se mal usado:
a) Ponto único de falha (SPOF)
Se o gateway cair, “cai tudo”.
Mitigação: alta disponibilidade, autoscaling, múltiplas réplicas, health checks, deploy sem downtime.
b) Gargalo de performance
Gateway pode virar gargalo se concentrar lógica demais.
Mitigação: manter responsabilidades claras, evitar lógica de negócio pesada, usar cache onde fizer sentido, monitorar latência.
c) “Monólito no gateway”
Quando regras de negócio começam a migrar para o gateway, ele vira um “mini-monólito”.
Mitigação: gateway para políticas e integração; negócio fica nos serviços.
d) Complexidade operacional
Gateway exige:
- configuração cuidadosa
- gestão de rotas
- certificados, chaves, plugins/policies
- observabilidade madura
Se sua aplicação é pequena (ex.: poucos serviços ou monólito), talvez um gateway robusto seja overkill.
Conclusão
O API Gateway é um dos componentes mais importantes para tornar microservices viáveis em produção, porque simplifica o acesso do cliente, centraliza segurança e políticas, melhora observabilidade e facilita evolução do backend.
Minha recomendação:
- Se você tem múltiplos serviços e múltiplos clientes, considere fortemente um gateway (ou BFF).
- Se seu sistema ainda é pequeno, comece simples e evolua: um gateway leve (ou um reverse proxy com algumas políticas) pode ser suficiente.
- Evite transformar o gateway em camada de negócio: ele deve ser porta de entrada e governança, não “o lugar onde tudo acontece”.
Referências
- NGINX Documentation — API Gateway
- Microsoft Azure Architecture Center — API Gateway pattern
- Kong — What is an API Gateway?