---
term: 'Arquitetura de API Gateway'
seoTitle: 'O que é um API Gateway? Arquitetura, Padrões e Trade-offs'
headline: 'O que é um API Gateway?'
slug: api-gateway
category: api-realtime
shortDefinition: 'Um API gateway é uma porta de entrada gerenciada para as suas APIs — um ponto único que roteia, autentica e aplica rate limit a cada requisição.'
relatedTerms:
  - api-rate-limiting-throttling
  - microservices-vs-monolith
  - api-orchestration
  - cors-cross-origin-resource-sharing
contrastsWith:
  - api-orchestration
faq:
  - question: 'O que é um API gateway e como ele funciona?'
    answer: 'É um ponto de entrada único na frente dos seus serviços de backend. Toda requisição chega ao gateway, que autentica quem chama, aplica rate limits, roteia para o serviço certo, opcionalmente transforma ou agrega respostas e registra dados de observabilidade — e então devolve o resultado. Os clientes veem uma API coerente; a topologia atrás dela permanece privada e livre para mudar.'
  - question: 'Qual a diferença entre API gateway e load balancer?'
    answer: 'Camada e intenção. O load balancer distribui tráfego entre cópias idênticas de um serviço, por capacidade e disponibilidade — ele pergunta "qual instância?". O gateway toma decisões cientes de API — "qual serviço, esse chamador pode, a que taxa, com qual transformação?". Eles se complementam: o arranjo clássico põe um load balancer na frente das instâncias do gateway, e os serviços atrás dos dois.'
  - question: 'Um API gateway é só um reverse proxy?'
    answer: 'É um reverse proxy especializado. Todo gateway é um proxy reverso — termina requisições de clientes e as encaminha para dentro — mas com um cérebro de políticas no formato de API: autenticação, rate limits por chave, transformação de requisições, agregação e observabilidade em nível de API. Se você só precisa de encaminhamento e TLS, um reverse proxy comum basta; o gateway se paga quando política entra em cena.'
  - question: 'Qual a diferença entre API gateway e service mesh?'
    answer: 'A direção do tráfego. O gateway governa o tráfego norte-sul — clientes entrando no sistema. O service mesh governa o tráfego leste-oeste — serviços conversando entre si por dentro, via sidecars que cuidam de mTLS, retries e roteamento. Sistemas grandes rodam os dois; sistemas pequenos geralmente não precisam do mesh — e às vezes nem do gateway.'
  - question: 'O que é o padrão Backend for Frontend (BFF)?'
    answer: 'Uma variação do gateway: em vez de um gateway atendendo todos os clientes, cada tipo de cliente — web, mobile, parceiros — ganha o seu próprio gateway fino, moldando respostas para as suas necessidades. Ele resolve o cabo de guerra em que uma API genérica atende todo mundo mal, ao custo de mais artefatos para implantar. O BFF é o padrão de gateway admitindo que clientes são diferentes.'
  - question: 'Um API gateway é um ponto único de falha?'
    answer: 'Arquiteturalmente, sim — tudo passa por ele — e é por isso que gateways de produção rodam como frotas clusterizadas e escaladas horizontalmente atrás de um load balancer, com health checks e failover. A mitigação é padrão; o pecado é rodar a porta-de-tudo como instância única porque funcionou bem em staging.'
  - question: 'Um API gateway adiciona latência?'
    answer: 'Um hop, tipicamente na casa de milissegundos de um dígito — e muitas vezes é ganho líquido: a agregação colapsa várias idas e vindas do cliente em uma, o cache responde repetições na borda, e a reutilização de conexões com os backends é mais rápida que conexões frias do cliente. A conta honesta compara o hop com as viagens e o código de política duplicado que ele elimina.'
  - question: 'Quando você NÃO precisa de um API gateway?'
    answer: 'Com mais frequência do que os vendedores admitem: um serviço único com um tipo de cliente, um app renderizado no servidor chamando o próprio backend, APIs internas atrás de uma VPN, ou qualquer lugar em que um reverse proxy existente já cubra TLS e roteamento. O gateway paga seu custo operacional quando há muitos serviços, muitos clientes ou política de verdade para centralizar — não antes.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API Gateway pattern — microservices.io'
    url: 'https://microservices.io/patterns/apigateway.html'
  - name: 'Backend for Frontends — Sam Newman'
    url: 'https://samnewman.io/patterns/architectural/bff/'
  - name: 'Envoy Proxy (open source)'
    url: 'https://www.envoyproxy.io/'
  - name: 'Cloud Code & backend guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/'
cta:
  title: 'A porta de entrada, já construída'
  text: 'O Back4app coloca um gateway gerenciado na frente de cada app: autenticação, rate limits e roteamento para APIs geradas automaticamente e Cloud Code — tudo imposto na borda da plataforma, sem infraestrutura de gateway para você implantar ou escalar.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: api-gateway-architecture
---

**Um API gateway é uma porta de entrada gerenciada para as suas APIs — um ponto único que roteia, autentica e aplica rate limit a cada requisição.** A ideia é centralização: o trabalho transversal de que todo endpoint precisa (quem é você, a que taxa pode chamar, para onde isso vai, o que aconteceu) sai de N serviços e entra em uma camada de política que os clientes não conseguem contornar.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O que é | Um ponto de entrada: rotear, autenticar, limitar, transformar, observar |
| vs. load balancer | O LB escolhe uma instância; o gateway toma decisões de política cientes de API |
| vs. reverse proxy | Um gateway *é* um — com um cérebro de políticas de API acoplado |
| vs. service mesh | Gateway = norte-sul (clientes entrando); mesh = leste-oeste (serviço a serviço) |
| A pergunta honesta | Se você precisa de um — muitos sistemas ainda não precisam |

## O que a porta de entrada faz

A lista de tarefas de um gateway, como configuração em vez de N cópias de middleware — uma rota declarativa típica:

```yaml
# rota do gateway: uma entrada, política anexada
route: /orders/**
  service: orders-api:8080          # roteamento — a topologia fica privada
  auth: bearer-jwt                  # autenticação na porta
  rate_limit: 100/min per key       # orçamentos antes dos backends
  transform:
    strip_headers: [X-Internal-*]   # traduzir entre a borda e o interior
  timeout: 5s
  observe: log + trace + metrics    # um só lugar para observar tudo
```

Do lado do cliente, um gateway gerenciado desaparece dentro do SDK — uma chamada, com as checagens da porta aplicadas antes de qualquer código seu rodar:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}
```

## Os quatro parecidos, separados

| | Reverse proxy | Load balancer | **API gateway** | Service mesh |
| --- | --- | --- | --- | --- |
| Pergunta que responde | "Encaminhe isso para dentro" | "Qual instância?" | **"Qual serviço, você pode, a que taxa?"** | "Como os serviços conversam com segurança?" |
| Tráfego | Norte-sul | Norte-sul | **Norte-sul** | Leste-oeste |
| Base da decisão | Host/path | Saúde + algoritmo | **Política de API: auth, limites, formato** | Identidade do serviço |
| Camada típica | L7 básico | L4/L7 | **L7, ciente de API** | Sidecars em todo lugar |
| Relação | Classe-mãe do gateway | Geralmente na frente do gateway | — | Coexiste atrás dele |

```mermaid
flowchart LR
  accTitle: Arquitetura de API gateway
  accDescr: Clientes web, mobile e parceiros enviam requisições a um load balancer na frente de um API gateway clusterizado, que autentica, aplica rate limits e roteia para serviços internos; os serviços e sua topologia ficam privados atrás dele.
  W["Web"] --> LB["Load balancer"]
  M["Mobile"] --> LB
  P["Parceiros"] --> LB
  LB --> G["API gateway (clusterizado)<br/>auth · limites · roteamento ·<br/>transformação · observabilidade"]
  G --> S1["Serviço de pedidos"]
  G --> S2["Serviço de usuários"]
  G --> S3["Serviço de busca"]
```

A [descrição canônica do padrão](https://microservices.io/patterns/apigateway.html) acrescenta a variação que vale conhecer: o **[Backend for Frontend](https://samnewman.io/patterns/architectural/bff/)** — um gateway fino *por tipo de cliente*, cada um moldando respostas para o seu cliente — que troca mais artefatos implantados pelo fim das APIs tamanho-único-que-não-serve-em-ninguém.

## As desvantagens, ditas sem rodeios

O gateway centraliza poder, e a centralização cobra de quatro formas. **Ponto único de falha:** tudo flui por ele — rode-o clusterizado atrás de um load balancer ou aceite que a queda dele é *a* queda. **O novo gargalo:** todo time de feature agora abre mudanças de configuração contra um componente compartilhado; governança e ferramentas de self-service são parte da adoção, não extras. **O monólito renascido:** lógica de agregação acumulando no gateway reconstrói em silêncio a aplicação centralizada que você decompôs — mantenha-o denso em política e magro em lógica. **Alastramento de config:** centenas de rotas com políticas por rota são um codebase; revise-as como um. Nada disso argumenta contra gateways; tudo isso argumenta contra gateways casuais.

## Casos de uso comuns

- **Porta de entrada de microsserviços** — a história de origem: muitos serviços, uma API coerente, topologia livre para evoluir atrás dela.
- **Produtos multi-cliente** — web, mobile e parceiros com auth, formatos e limites diferentes — o território do BFF.
- **Monetização de API** — chaves, planos, quotas e medição de uso impostos em um ponto.
- **Migrações** — o padrão strangler: o gateway roteia caminhos antigos para o sistema legado e caminhos novos para o substituto, de forma invisível.
- **Política de borda** — CORS, TLS, higiene de headers e [rate limiting](/glossary/pt/rate-limiting-de-api/) aplicados uma vez em vez de N.

## Você precisa de um? Matriz de decisão

| O gateway se paga quando… | Pule (ou adie) quando… |
| --- | --- |
| Muitos serviços ficam atrás de uma API | Um serviço atende um tipo de cliente |
| Clientes diferem em auth, formato ou limites | Um reverse proxy já cobre TLS + roteamento |
| A política precisa ser imposta centralmente | A política está a um import de middleware de distância |
| A topologia muda mais rápido que os clientes | A topologia é uma caixa só |
| Alguém é dono do gateway como produto | Ninguém o operaria |

A resposta sem dono na maioria das páginas de comparação: **ainda não** é uma arquitetura legítima. Adicione a porta quando houver um prédio atrás dela.

## Limitações e trade-offs

- **A disponibilidade agora é a disponibilidade do gateway.** Clusterize, monitore com health checks e ensaie a falha dele — a mitigação é padrão e não é opcional.
- **Um hop de latência, contabilizado com honestidade** contra as idas e vindas e o middleware duplicado que ele remove; meça, não presuma em nenhuma direção.
- **Agregação é uma ladeira.** Compor respostas é legítimo; lógica de negócio no gateway é o padrão ESB usando um crachá novo.
- **Opções open-source carregam operação.** Existem gateways excelentes em open source (stacks baseados em Envoy e pares) — cada um é um sistema distribuído que você agora roda, atualiza e protege.
- **Gateways gerenciados trocam controle por silêncio.** A porta operada pela plataforma é a resposta certa exatamente quando operar o gateway seria labuta sem diferencial.

## O gateway no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A camada de gateway vem com a plataforma: toda requisição — REST, GraphQL, SDK ou chamada de Cloud Code, como nas abas de código acima — entra por uma borda gerenciada que autentica sessões e chaves, aplica rate limits por app e roteia para as APIs geradas ou para as suas funções, com a plataforma operando o clustering e a escalabilidade que tornam uma porta de entrada segura. A matriz de decisão colapsa: você ganha as garantias do gateway no primeiro dia, e pula a posse da porta por inteiro.