API Gateway

O problema

Sem um ponto de entrada, cada cliente precisa conhecer o endereço de N serviços, autenticar-se N vezes, lidar com N políticas de CORS e acompanhar cada mudança de topologia (um serviço que se divide quebra todos os clientes). Clientes móveis ainda sofrem chattiness: várias chamadas de rede para montar uma tela.

A solução

Um serviço de borda por onde todo tráfego externo entra:

Roteamento — mapeia rotas públicas para serviços internos, escondendo a topologia.
Preocupações transversais — autenticação/autorização, rate limiting, terminação TLS, logging e métricas em um só lugar, em vez de repetidos em cada serviço.
Agregação leve — pode hospedar o composer de API Composition para reduzir round-trips do cliente.
Resiliência na borda — Circuit Breaker e Fallback aplicados às rotas.

graph LR
    W[Cliente Web] --> GW["API Gateway<br/>(auth, rate limit, rotas)"]
    M[Cliente Mobile] --> GW
    GW --> P[Pedidos]
    GW --> C[Clientes]
    GW --> E[Entregas]

Variante: BFF (Backend for Frontend)

Quando clientes distintos têm necessidades muito diferentes (web rica vs. mobile enxuto vs. parceiros), um gateway único genérico vira campo de batalha entre times. O BFF dá um gateway por tipo de cliente, mantido pelo time daquele frontend, cada um agregando e formatando como seu cliente precisa.

Exemplo: Spring Cloud Gateway

spring:
  cloud:
    gateway:
      routes:
        - id: pedidos
          uri: lb://pedido-service
          predicates:
            - Path=/api/pedidos/**
          filters:
            - StripPrefix=1
            - name: CircuitBreaker
              args:
                name: pedidos
                fallbackUri: forward:/fallback/pedidos

A rota pública /api/pedidos/** é reescrita e balanceada (lb://) para o serviço interno, com Circuit Breaker e fallback aplicados na borda — os clientes nunca conhecem pedido-service.

Anti-padrões e erros comuns

Gateway gordo: regra de negócio migrando para o gateway — vira um monólito na borda que todos os times precisam alterar.
Ponto único de falha: gateway sem alta disponibilidade derruba o sistema inteiro; ele precisa de réplicas e das mesmas práticas de resiliência que impõe.
Bypass: clientes (ou serviços) chamando serviços internos diretamente, furando autenticação e políticas da borda.
Um BFF “genérico”: um único gateway tentando servir web, mobile e parceiros acaba com o pior dos três mundos — se as necessidades divergem, divida por cliente.

Relações

Borda de entrada de Microservices e das APIs - REST, GraphQL e gRPC.
Pode hospedar API Composition e aplicar Circuit Breaker/Fallback/Retry por rota.
Contraste de direção: Gateway (PoEAA) e Adapters.
Índice: Microservices Patterns · Sistemas Distribuídos · Catálogo de Patterns.

Perguntas de revisão

1. Quais preocupações o API Gateway centraliza?

Resposta

Roteamento (escondendo a topologia interna), autenticação/autorização, rate limiting, TLS, observabilidade da borda e, opcionalmente, agregação de respostas e resiliência (circuit breaker/fallback) por rota.

2. Quando a variante BFF compensa?

Resposta

Quando tipos de cliente com necessidades muito diferentes disputam o mesmo gateway genérico. Um gateway por tipo de cliente, mantido pelo time daquele frontend, elimina o conflito e permite agregação sob medida.

3. Qual a diferença entre API Gateway e o Gateway de Fowler?

Resposta

Direção. O API Gateway é infraestrutura de entrada — recebe tráfego externo e roteia para dentro. O Gateway do PoEAA é um objeto de saída — a aplicação o usa para acessar um recurso externo.

4. Por que regra de negócio no gateway é anti-padrão?

Resposta

Porque transforma a borda num monólito compartilhado: todos os times passam a editar o mesmo componente, o deploy independente morre e a regra fica longe do Bounded Context que a possui. O gateway roteia e protege; quem decide é o serviço.