É muito comum ver esses dois termos sendo usados quase como sinônimos — e, tecnicamente, não estão totalmente errados quem faz isso, porque todo API Gateway é, na sua essência, um tipo de proxy reverso. Mas tratá-los como a mesma coisa esconde diferenças importantes de propósito, funcionalidades e onde cada um se encaixa numa arquitetura. Neste post, vamos destrinchar os dois conceitos, entender a relação entre eles e quando faz sentido usar cada um.
O que é um Proxy Reverso
Um proxy reverso é um servidor que fica na frente de um ou mais servidores backend, recebendo as requisições dos clientes e repassando essas requisições para o servidor apropriado, devolvendo a resposta de volta pro cliente. Do ponto de vista de quem está fazendo a requisição, é como se estivesse falando diretamente com o proxy — o backend real fica invisível.
Cliente → Proxy Reverso → Servidor Backend
O termo "reverso" existe em contraste com o proxy tradicional (forward proxy), que fica na frente do cliente, não do servidor — usado, por exemplo, quando uma empresa quer controlar/filtrar o acesso dos funcionários à internet. No proxy reverso, é o contrário: ele protege e representa o servidor, não o cliente.
Funções típicas de um proxy reverso
- Encaminhamento de requisições para o servidor correto (
proxy_passno Nginx, por exemplo) - Balanceamento de carga entre múltiplas instâncias de um mesmo serviço
- Terminação SSL/TLS: o proxy lida com a criptografia HTTPS, enquanto o backend recebe tráfego HTTP simples internamente
- Cache de respostas: evitando que o backend precise reprocessar a mesma requisição repetidamente
- Compressão (lembra do gzip que vimos anteriormente?): comprimindo respostas antes de enviar ao cliente
- Ocultar a topologia interna: o cliente não sabe quantos servidores existem por trás, nem seus endereços reais
Nginx, Apache (com mod_proxy), HAProxy e Traefik são exemplos clássicos de ferramentas usadas como proxy reverso.
O que é um API Gateway
Um API Gateway também atua como um ponto único de entrada — nesse sentido, ele é um proxy reverso por baixo dos panos. Mas ele foi desenhado especificamente para resolver um problema diferente: gerenciar o acesso a um conjunto de APIs, geralmente numa arquitetura de microsserviços.
Cliente → API Gateway → Serviço A
→ Serviço B
→ Serviço C
Enquanto um proxy reverso genérico se preocupa principalmente em "pra onde mando essa requisição", um API Gateway se preocupa com uma camada bem mais rica de regras de negócio e controle em torno de cada chamada de API.
Funções típicas de um API Gateway (além do que o proxy já faz)
- Autenticação e autorização: validar tokens JWT, chaves de API, OAuth, antes mesmo da requisição chegar no serviço de destino
- Rate limiting por cliente/API key: controlar quantas chamadas cada consumidor da API pode fazer num intervalo de tempo — não só uma proteção genérica de tráfego, mas uma regra de negócio por cliente
- Roteamento baseado em conteúdo da requisição: direcionar pra serviços diferentes baseado no path, em headers customizados, na versão da API (
/v1/,/v2/) etc - Agregação de respostas: combinar dados de múltiplos microsserviços numa única resposta pro cliente (evitando que o cliente precise fazer várias chamadas separadas)
- Transformação de payload: converter formatos entre o que o cliente espera e o que cada serviço interno retorna (por exemplo, XML para JSON)
- Observabilidade centralizada: métricas, logs e tracing de todas as chamadas de API num único ponto
- Versionamento e depreciação de APIs: gerenciar múltiplas versões coexistindo e comunicar quando uma versão antiga será descontinuada
- Circuit breaking: interromper temporariamente chamadas pra um serviço que está falhando, evitando sobrecarga em cascata
Exemplos de ferramentas voltadas especificamente para isso: Kong, Amazon API Gateway, Apigee (Google), Tyk, Azure API Management.
A relação entre os dois
A forma mais precisa de pensar nisso é:
Um API Gateway é um proxy reverso especializado, com uma camada adicional de funcionalidades voltadas especificamente para gerenciamento de APIs.
Ou, em outras palavras: todo API Gateway é um proxy reverso, mas nem todo proxy reverso é um API Gateway.
Um Nginx configurado só com proxy_pass simples, sem autenticação, sem rate limiting por cliente, sem agregação — está fazendo o trabalho de proxy reverso, mas não está atuando como um API Gateway completo. Só que é bem comum, na prática, configurar o próprio Nginx (ou HAProxy) com módulos e configurações adicionais pra assumir várias responsabilidades de um Gateway — a linha entre os dois fica bem tênue dependendo de quanto você configura.
Tabela comparativa
| Aspecto | Proxy Reverso (genérico) | API Gateway |
|---|---|---|
| Função principal | Encaminhar requisições HTTP | Gerenciar o ciclo de vida de chamadas de API |
| Foco | Infraestrutura de rede | Regras de negócio + infraestrutura |
| Autenticação/autorização | Geralmente não nativo (precisa de módulo extra) | Nativo, é uma das funções centrais |
| Rate limiting | Por IP/conexão, de forma genérica | Por cliente/API key, com granularidade de negócio |
| Agregação de respostas | Não | Sim, comum em arquiteturas de microsserviços |
| Transformação de dados | Não | Sim (ex: XML → JSON) |
| Versionamento de API | Não é uma preocupação nativa | Recurso central |
| Exemplos de ferramentas | Nginx, HAProxy, Apache | Kong, Apigee, AWS API Gateway, Tyk |
| Usado tipicamente para | Servir sites, balancear carga, terminar SSL | Expor e gerenciar APIs para consumidores externos/internos |
Quando usar cada um (ou os dois juntos)
Na prática, muitas arquiteturas usam ambos, em camadas diferentes:
Internet → Proxy Reverso (Nginx/CDN)
↓ (SSL termination, cache estático, proteção DDoS básica)
API Gateway (Kong/AWS API Gateway)
↓ (autenticação, rate limiting por cliente, roteamento)
Microsserviços internos
- Só proxy reverso costuma ser suficiente quando você tem uma aplicação relativamente simples, monolítica ou com poucos serviços, e as necessidades são mais de infraestrutura (SSL, balanceamento, cache) do que de gestão fina de consumidores de API.
- API Gateway se torna importante quando você tem uma arquitetura de microsserviços de fato, com múltiplos serviços internos, múltiplos consumidores externos (parceiros, apps mobile, terceiros), e precisa de controle centralizado sobre quem acessa o quê, com que limite, e como.
Vale notar que usar um API Gateway "só porque é moderno" numa aplicação pequena costuma ser complexidade desnecessária — é uma ferramenta que resolve problemas específicos de escala e governança de APIs, não um upgrade automático que toda aplicação precisa.
Resumindo
Proxy reverso e API Gateway não são conceitos concorrentes, mas sim camadas com escopos diferentes: o proxy reverso resolve o problema de "pra onde essa requisição deve ir, e como lidar com aspectos de rede no caminho"; o API Gateway resolve o problema mais amplo de "como eu governo, protejo e organizo o acesso a um conjunto de APIs que meus serviços expõem". Um API Gateway é construído sobre o conceito de proxy reverso, adicionando uma camada de inteligência voltada a regras de negócio em torno de cada chamada.
Entender essa diferença ajuda bastante na hora de escolher a ferramenta certa: às vezes um Nginx bem configurado resolve tudo que você precisa; em outros casos, especialmente em arquiteturas de microsserviços maiores, um API Gateway dedicado evita que você tenha que reinventar (e manter) manualmente um monte de lógica de autenticação, rate limiting e roteamento espalhada por configurações de proxy.