API Gateway

Um API Gateway é a porta de entrada única para os clientes de um sistema baseado em microsserviços. Em vez do cliente conhecer e chamar diretamente cada serviço individual, ele fala só com o gateway, que decide para onde encaminhar cada requisição.

flowchart LR
    Client[Cliente] --> GW[API Gateway]
    GW --> S1[Serviço de Usuários]
    GW --> S2[Serviço de Pedidos]
    GW --> S3[Serviço de Pagamentos]

Responsabilidades

Concentrar as requisições num único ponto de entrada permite centralizar preocupações que, de outra forma, cada microsserviço precisaria implementar por conta própria:

• Roteamento: decide, com base na URL ou em outros dados da requisição, qual serviço deve tratá-la (ex: /usuarios/* vai para o serviço de usuários).
• Autenticação: verifica se quem está fazendo a requisição é quem diz ser (ex: validar um token JWT), antes de deixar a requisição seguir adiante.
• Autorização: verifica se, além de autenticado, o usuário tem permissão para aquela ação específica.
• Rate limiting: limita quantas requisições um cliente pode fazer num intervalo de tempo, protegendo os serviços de trás contra abuso ou picos excessivos (aprofundado em Rate Limiting).
• TLS termination: o gateway é quem lida com a criptografia HTTPS na borda do sistema; a comunicação entre o gateway e os serviços internos pode acontecer sem esse custo extra, dentro de uma rede já considerada confiável.
• Logging: registra as requisições que entram no sistema num único lugar, o que facilita auditoria e depuração.
• Observabilidade: como todo tráfego passa por ele, o gateway é um ponto natural para coletar métricas (quantas requisições, quanto tempo cada uma leva, quantos erros) do sistema como um todo, alimentando o que é aprofundado em Observabilidade.

Sem um API Gateway, cada microsserviço teria que reimplementar autenticação, rate limiting e logging por conta própria, o que gera duplicação de código e inconsistência (um serviço valida o token diferente do outro).

API Gateway vs Load Balancer

É comum confundir os dois, porque ambos ficam “na frente” dos serviços e distribuem tráfego, mas eles resolvem problemas em camadas diferentes:

	Load Balancer	API Gateway
Onde atua	Tipicamente L4 ou L7, distribuindo tráfego entre réplicas do mesmo serviço	L7, roteando entre serviços diferentes com base em regras de negócio
Decisão principal	”Qual instância está livre para atender?"	"Qual serviço trata esse tipo de requisição, e essa requisição tem permissão para chegar até lá?”
Preocupações típicas	Distribuição de carga, health check, failover	Autenticação, autorização, rate limiting, roteamento por rota/versão de API

Na prática, os dois normalmente coexistem no mesmo sistema: o load balancer distribui tráfego entre as réplicas do próprio API Gateway (que também escala horizontalmente), e depois o gateway roteia cada requisição para o load balancer (ou diretamente para as instâncias) do microsserviço correto.

flowchart LR
    Client[Cliente] --> LB1[Load Balancer]
    LB1 --> GW1[API Gateway 1]
    LB1 --> GW2[API Gateway 2]
    GW1 --> LB2[Load Balancer<br/>Serviço de Pedidos]
    LB2 --> P1[Instância 1]
    LB2 --> P2[Instância 2]

API Gateway vs Load Balancer vs Reverse Proxy

Quando entra o terceiro personagem, o reverse proxy, a confusão aumenta, porque os três ficam na frente dos serviços, recebem a requisição e repassam adiante. O jeito mais útil de separar é pela pergunta que cada um responde:

Componente	Pergunta que responde	Exemplo de decisão
Reverse proxy	”Por onde a requisição entra e para onde ela vai?”	blog.loja.com vai para o servidor do blog, com TLS terminado aqui
Load balancer	”Qual instância atende esta requisição?”	Das 4 réplicas saudáveis da API, manda para a réplica 3
API Gateway	”Esta requisição pode passar? E de que jeito?”	Token válido, dentro do limite de 100 req/min, roteia para /v2/pedidos

Onde eles se sobrepõem

Na prática, a fronteira é borrada. Um load balancer L7 e um API Gateway são reverse proxies, só que especializados: o primeiro é um reverse proxy focado em distribuir carga entre réplicas, o segundo é um reverse proxy focado em políticas de API. Por isso uma mesma ferramenta pode fazer os três papéis. Um NGINX bem configurado termina TLS, distribui entre instâncias com um bloco upstream e aplica rate limiting por rota, tudo no mesmo arquivo de configuração.

O que muda não é o software, é o papel que ele está cumprindo naquele ponto da arquitetura.

Nem todo load balancer é proxy

A recíproca não vale sempre. Alguns load balancers não ficam no caminho completo da requisição:

• L4 em modo Direct Server Return (DSR): o load balancer recebe só a ida. Ele repassa o pacote para o servidor escolhido trocando apenas o endereço MAC de destino (camada de enlace), e o servidor responde direto para o cliente, sem voltar pelo balanceador. Como as respostas costumam ser bem maiores que as requisições, isso alivia muito o load balancer. O preço: ele não enxerga HTTP, então não dá para fazer TLS termination, cache ou roteamento por URL.
• Balanceamento via DNS: o servidor de DNS devolve IPs diferentes para clientes diferentes, e cada cliente conecta direto no servidor que recebeu. Não existe nenhum intermediário no caminho dos dados.

Nesses casos não há proxy nenhum, só a escolha de destino.

Composição em camadas

Em sistemas maiores, os três aparecem empilhados, cada um fazendo o seu pedaço:

flowchart LR
    C[Cliente] --> CDN[CDN / reverse proxy<br/>na borda]
    CDN --> LB[Load balancer]
    LB --> GW1[API Gateway 1]
    LB --> GW2[API Gateway 2]
    GW1 --> S1[Serviço de Pedidos]
    GW1 --> S2[Serviço de Usuários]
    GW2 --> S1
    GW2 --> S2

A CDN absorve tráfego estático e ataques na borda, o load balancer espalha o que sobra entre as réplicas do gateway, e o gateway aplica autenticação, rate limiting e roteamento até o serviço certo.

Cuidado com políticas duplicadas

Empilhar camadas tem um efeito colateral pouco óbvio: cada uma costuma vir com suas próprias configurações de timeout e retry. Se o load balancer tenta 3 vezes e o gateway, a cada tentativa, também tenta 3 vezes, um serviço lento recebe até 9 chamadas para cada requisição do cliente, justamente quando ele já está sofrendo. 😬

O mesmo vale para timeouts desalinhados: se o gateway desiste em 5 segundos mas o load balancer na frente dele desiste em 2, o cliente recebe erro enquanto o gateway ainda está trabalhando à toa. A regra prática é decidir uma camada responsável por retry, e configurar os timeouts de fora para dentro em ordem decrescente (a camada mais externa espera um pouco mais que a de dentro).

Como escolher

Comece pela intenção, não pela ferramenta:

• Precisa só publicar uma aplicação com HTTPS, cache e esconder o servidor? Um reverse proxy resolve.
• Tem várias réplicas do mesmo serviço e precisa espalhar carga e tirar instâncias doentes do caminho? É trabalho de load balancer.
• Tem vários serviços expostos para clientes diferentes e quer centralizar autenticação, rate limiting e versionamento? Aí entra o API Gateway.

Num sistema pequeno, um único NGINX costuma cobrir as três intenções. Separar em componentes dedicados faz sentido quando cada papel passa a ter dono, escala ou ciclo de mudança diferente.

Padrões avançados de gateway

As responsabilidades já vistas (roteamento, auth, rate limiting) cobrem a maior parte do que um gateway faz no dia a dia. Mas dois problemas específicos, que aparecem sobretudo em sistemas com muitos clientes diferentes consumindo o mesmo backend, merecem um olhar à parte.

Agregação de requisições (BFF)

Uma tela de dashboard raramente depende de um único serviço. Ela pode precisar do perfil do usuário, dos pedidos recentes e do status de pagamentos, tudo ao mesmo tempo. Sem ajuda do gateway, o cliente teria que fazer três chamadas separadas e juntar o resultado sozinho:

sequenceDiagram
    participant Client
    participant GW as API Gateway
    participant U as user-service
    participant O as order-service
    participant P as payment-service

    Client->>GW: GET /dashboard
    GW->>U: GET /users
    GW->>O: GET /orders
    GW->>P: GET /payments
    U-->>GW: dados do usuário
    O-->>GW: pedidos
    P-->>GW: pagamentos
    GW-->>Client: resposta agregada (JSON único)

O BFF (Backend for Frontend) é esse papel de agregação vivendo no gateway: ele recebe a chamada única do cliente (GET /dashboard), dispara as chamadas necessárias para os serviços internos, junta as respostas num JSON só e devolve pro cliente. Isso reduz o número de idas e voltas entre cliente e servidor (roundtrips), o que importa bastante em conexões mais lentas, como redes móveis, onde cada roundtrip a mais custa latência real.

Vale notar uma diferença de escopo: BFF, como padrão, é às vezes implementado como um serviço dedicado por tipo de cliente (um BFF só para mobile, outro só para web), não necessariamente dentro do gateway genérico. Mas a ideia central, agregar múltiplas chamadas de backend numa resposta pensada para o cliente, é a mesma nos dois casos, e um gateway já centralizado é um lugar natural para implementar essa agregação quando não vale a pena manter um serviço BFF separado.

Adaptação de API

O segundo problema aparece quando clientes diferentes esperam formatos diferentes do mesmo dado. Um app mobile antigo, ainda não atualizado, pode falar a versão v1 de um endpoint, enquanto a versão web mais nova já fala v2, com um payload mais rico:

flowchart LR
    Web[Cliente Web<br/>v2] -->|GET /v2/home| GW[API Gateway]
    Mobile[Cliente Mobile<br/>v1] -->|GET /v1/home| GW
    GW -->|adapta e roteia| US[user-service]

Em vez de manter duas versões inteiras de cada microsserviço só para atender clientes em versões diferentes, o gateway pode concentrar essa adaptação:

• Versionamento: rotear /v1/* e /v2/* para o serviço certo, ou até para a mesma versão do serviço, aplicando uma transformação de payload no meio do caminho, seguindo as estratégias de versionamento já vistas em Segurança e Evolução de APIs.
• Transformação de payload: reduzir o payload para o cliente mobile (menos campos, dados mais compactos, pensando em banda e bateria) e manter o payload completo para o cliente web, sem duplicar lógica de negócio no serviço de origem.

Isso mantém os microsserviços de trás enxutos, falando uma única versão do contrato internamente, enquanto o gateway absorve a complexidade de traduzir esse contrato para o que cada geração de cliente espera.

Quando utilizar um API Gateway: sistemas com múltiplos microsserviços, especialmente quando existem preocupações transversais (auth, rate limiting) que se repetiriam em cada serviço, ou quando clientes diferentes (app mobile, web, parceiros externos) precisam de formas diferentes de acessar o mesmo conjunto de serviços.

Quando não utilizar: em um monólito ou sistema pequeno com poucos serviços, um API Gateway completo pode ser complexidade desnecessária, um load balancer sozinho já resolve o problema de distribuir tráfego, e autenticação pode viver direto na aplicação sem custo real de duplicação.

O que evitar

• O antipadrão do “gateway Deus”: acontece quando lógica de negócio vai migrando aos poucos para dentro do gateway. Começa pequeno, uma validação aqui, uma regra específica de um cliente ali, e alguns meses depois o gateway decide preço, aplica desconto e sabe coisas sobre o domínio que deveriam estar só no serviço dono daquele domínio. Nesse ponto o gateway virou um novo monolito bem no meio do caminho, só que sem os benefícios de organização de um: qualquer time que precisa mudar uma regra de negócio precisa mexer (e fazer deploy) num componente compartilhado por todo o sistema.
• O que pertence ao gateway: cross-cutting concerns, ou seja, preocupações que se repetiriam em todo serviço se não fossem centralizadas: autenticação, rate limiting, roteamento, TLS termination, observabilidade. Nenhuma dessas depende de saber como o domínio de negócio funciona.
• O que não pertence ao gateway: regra de negócio do domínio. Calcular o valor de um pedido com desconto, decidir se um item pode ser cancelado, validar se um cliente pode fazer determinada operação, isso é responsabilidade do serviço dono daquele dado, não do gateway.
• Sintoma de alerta: se mudar uma regra de negócio (não uma política de acesso ou de tráfego) exige deploy do gateway em vez de só do serviço dono da regra, a fronteira já foi cruzada. Nesse momento vale revisar o que foi parar ali e mover de volta para o serviço certo antes que o gateway vire um gargalo de organização, do mesmo jeito que o Enterprise Service Bus virava um gargalo na era do SOA.

Referências

• API Gateway: por que ele é peça-chave em arquiteturas de microservices (e quando evitar) - Paulo Henrique Fusco, pt-BR
• API Gateway vs Reverse Proxy vs Load Balancer - API7.ai, en
• Layer 4 load balancing Direct Server Return mode - HAProxy Technologies, en