Gateway Routing

Conceito

Um único ponto de entrada roteia requisições para serviços diferentes com base no path, host, header ou versão.

api.exemplo.com/pedidos/*   → serviço-pedidos
api.exemplo.com/usuarios/*  → serviço-usuarios
api.exemplo.com/v2/*        → nova versão

O cliente conhece um endereço; a topologia interna fica escondida.

Trade-offs

O ganho é desacoplamento entre cliente e topologia: dividir um serviço em dois, mover para outro host, ou publicar uma versão nova são mudanças de configuração no gateway, invisíveis para o cliente. É também o que permite deploy canário e blue-green por peso de tráfego.

Os custos:

Mais um salto de rede em todo o caminho, com a latência correspondente.

Ponto único de falha. O gateway precisa da própria redundância — normalmente um serviço gerenciado ou um par ativo-ativo atrás de DNS.

Concentração de configuração. Regras de roteamento se acumulam e viram um sistema que ninguém entende inteiro. Um deploy de configuração do gateway passa a ser tão arriscado quanto um deploy de código, e merece o mesmo cuidado — versionamento, revisão, rollback.

O antipadrão a evitar é o gateway com lógica de negócio. Roteamento, autenticação e rate limit pertencem ali; regra de domínio, não. Quando o gateway começa a decidir coisas sobre pedidos ou usuários, ele vira um monolito disfarçado que acopla todos os serviços.

Exemplo prático

/api/pedidos/*   → pedidos-v1     (10 instâncias)
/api/pedidos/v2/* → pedidos-v2    (2 instâncias, canário 5%)
/api/usuarios/*  → usuarios
/static/*        → CDN
/*               → frontend

Migrar pedidos para uma versão nova é ajustar o peso: 5%, observar métricas, 25%, 100%. Reverter é voltar o peso a zero.

Sem o gateway, cada cliente precisaria conhecer o endereço de cada serviço, e uma migração exigiria coordenar a atualização de todos eles.

Relacionado

• Strangler Fig
• Sidecar
• Static Content Hosting
• Leader Election

---

Parte de Design & Implementation · roadmap.sh/system-design