API Gateway

Analogia

A recepção do hotel

Você não bate na porta de cada funcionário do hotel — governança, cozinha, manutenção. Você fala com a recepção, que confere sua identidade uma vez, sabe a quem encaminhar cada pedido e esconde de você a estrutura interna do hotel. Se a cozinha muda de andar, você nem fica sabendo: continua ligando para a recepção. O API Gateway é essa recepção: um ponto de entrada que autentica, encaminha e blinda o hóspede da bagunça de dentro. E, como toda recepção, se ela para, ninguém entra — por isso ela não pode ser uma pessoa só, num balcão só.

01Conceito

Duas funções: o transversal e a fachada

O gateway resolve dois problemas que andam juntos. Primeiro, o transversal: auth, rate limit, CORS, log são iguais para todos os serviços; concentrá-los na borda evita reimplementar (e divergir) em cada um. Segundo, a fachada: o cliente conhece um endereço só, e a topologia de serviços fica escondida e livre para mudar.

Os dois ganhos têm o mesmo preço: tudo passa por um ponto. Isso o torna candidato a gargalo e ponto único de falha — um gateway fora do ar tranca a entrada do sistema inteiro, então ele precisa de alta disponibilidade de verdade.

A confusão mais comum é com o BFF, e a distinção é limpa: o gateway é um portão para todos, focado no transversal e no roteamento; o BFF é um portão por cliente, focado em moldar a resposta àquela interface (agregar, enxugar). Não competem — muitos sistemas têm o gateway na frente cuidando de auth e limite, e atrás dele um BFF por tipo de cliente cuidando da forma. Misturá-los produz um gateway que também formata respostas, acumulando responsabilidades que deveriam estar separadas.

O maior perigo do gateway é a gravitação de responsabilidades. Como tudo passa por ele, é tentador colocar 'só mais uma coisinha' — uma transformação de payload aqui, uma regra de negócio ali — até ele virar um monólito de fronteira que todo time precisa tocar e todo deploy precisa coordenar. Aí o gateway reintroduz exatamente o acoplamento que os microsserviços atrás dele tentavam evitar. A disciplina é mantê-lo fino: roteamento e transversal genérico, sem regra de domínio. O que é lógica de negócio vive nos serviços; o que é forma por cliente vive no BFF.

02No mundo real

Como isso aparece na prática

A autenticação copiada em doze serviços

Cenário

Cada um dos doze serviços validava o token JWT por conta própria. Uma mudança na política de expiração exigia alterar e reimplantar os doze, e um deles ficou para trás, aceitando tokens que os outros já rejeitavam.

Como o padrão entra

A validação de token subiu para o API Gateway, executada uma vez na entrada. Os serviços passaram a confiar num cabeçalho de identidade já validado pelo gateway.

Trade-off: A autenticação virou responsabilidade de um ponto central, que precisa de alta disponibilidade. Em troca, a política passou a mudar num lugar só, e a divergência entre serviços acabou.

O gateway que virou monólito de fronteira

Cenário

Ao longo do tempo, o gateway foi acumulando transformações de payload e regras de negócio 'porque era conveniente'. Virou um componente que todos os times precisavam alterar, e cada mudança nele arriscava derrubar a entrada inteira.

Como o padrão entra

As regras de negócio foram devolvidas aos serviços, e a formatação por cliente foi movida para BFFs. O gateway voltou a fazer só roteamento e o transversal genérico.

Trade-off: Surgiram BFFs e mais responsabilidade nos serviços. É o desenho correto: o gateway magro deixou de ser o gargalo de deploy que ele mesmo havia virado.

03Cuidado

Onde isto dá errado

Encher o gateway de regra de negócio
Como tudo passa por ele, o gateway atrai 'só mais uma coisinha' até virar um monólito de fronteira que todo deploy precisa tocar. Ele reintroduz o acoplamento que os microsserviços evitavam. Mantenha-o fino: roteamento e transversal, sem domínio.
Tratá-lo como se não fosse ponto único de falha
Se o gateway cai, a entrada do sistema inteiro cai com ele. Sem alta disponibilidade real — réplicas, health check, failover —, concentrar tudo num ponto troca N problemas isolados por um problema total.
Confundir gateway com BFF
O gateway é um portão para todos, focado no transversal; o BFF é por cliente, focado em moldar a resposta. Fundir os dois incha o gateway com formatação por cliente — responsabilidades que rendem mais separadas.

04Implementação

Entrada única, transversal na borda

// Sem gateway: cada cliente conhece a topologia de servicos, e CADA
// servico reimplementa auth, rate limit, CORS, log... o mesmo, N vezes.

// COM API Gateway: um ponto unico de entrada. O cliente conhece so ele.
// Ele faz o transversal UMA vez e roteia para o servico interno certo.
gateway
  .use(autenticar)          // valida o token AQUI, uma vez para todos
  .use(rateLimit({ rpm: 600 }))
  .use(cors());

gateway.route("/pedidos/*",  "http://servico-pedidos");
gateway.route("/estoque/*",  "http://servico-estoque");
gateway.route("/pagamentos/*", "http://servico-pagamentos");
// O cliente chama sempre "gateway/pedidos/..." e nao sabe (nem precisa
// saber) que atras existem 3, 10 ou 50 servicos, nem onde eles estao.

// A tentacao a vigiar: encher o gateway de regra de negocio ate ele
// virar um monolito de fronteira que todo deploy precisa tocar.

05Decisão

Quando usar × quando evitar

Use quando

Num sistema de vários serviços que precisa de entrada única.
Para concentrar auth, rate limit e roteamento fora dos serviços.
Para esconder a topologia e reorganizar serviços sem quebrar clientes.

Evite quando

Quando há um serviço só.
Quando ele acumularia regra de negócio até virar monólito de fronteira.

Testar o que ficou

3 armadilhas de API Gateway viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.

Onde isto aparece de verdade

Você já usa isto, talvez sem saber o nome.

Kong, AWS API Gateway, ZuulOs produtos e serviços que implementam o ponto único de entrada de um sistema de microsserviços.
auth e rate limit num lugar sóConcentrar autenticação, limite de taxa e roteamento na entrada, para que os serviços não repitam isso cada um.
o /api que roteia para tudoO endereço único que o cliente conhece, escondendo atrás de si a topologia de serviços que muda por dentro.

O padrão em uma linha

Sem nome de domínio, sem cerimônia. Só a ideia.

// Uma porta: auth, rate limit e roteamento antes dos serviços.
app.use(gateway.auth);
app.use("/pedidos", pedidosRouter);

O que ele cobra

1 salto a mais entre a chamada e o efeito.

Um ponto único que, se cair, derruba a entrada de tudo — precisa de alta disponibilidade e vira candidato a gargalo
Concentrar responsabilidades transversais tenta inflá-lo até virar um monólito de fronteira

Não vale se: há um serviço só atrás dele — sem uma topologia de vários serviços para esconder e unificar, o gateway é um salto de rede sem função.