---
term: 'API Gateway Architecture'
seoTitle: 'What is an API Gateway? Architecture, Patterns & Trade-offs'
headline: 'What is an API Gateway?'
slug: api-gateway-architecture
category: api-realtime
shortDefinition: 'An API gateway is a managed front door for your APIs — one entry point that routes, authenticates, and rate-limits every request.'
relatedTerms:
  - api-rate-limiting-throttling
  - microservices-vs-monolith
  - api-orchestration
  - cors-cross-origin-resource-sharing
contrastsWith:
  - api-orchestration
faq:
  - question: 'What is an API gateway and how does it work?'
    answer: 'A single entry point sitting in front of your backend services. Every request arrives at the gateway, which authenticates the caller, applies rate limits, routes to the right service, optionally transforms or aggregates responses, and records observability data — then returns the result. Clients see one coherent API; the topology behind it stays private and changeable.'
  - question: 'What is the difference between an API gateway and a load balancer?'
    answer: 'Layer and intent. A load balancer distributes traffic across identical copies of a service for capacity and availability — it asks "which instance?" A gateway makes API-aware decisions — "which service, is this caller allowed, at what rate, with what transformation?" They are complementary: the classic arrangement runs a load balancer in front of gateway instances, and services behind both.'
  - question: 'Is an API gateway just a reverse proxy?'
    answer: 'It is a specialized one. Every gateway is a reverse proxy — it terminates client requests and forwards them inward — but with an API-shaped policy brain: authentication, per-key rate limits, request transformation, aggregation, and API-level observability. If you only need forwarding and TLS, a plain reverse proxy is enough; the gateway earns its keep when policy enters.'
  - question: 'What is the difference between an API gateway and a service mesh?'
    answer: 'Traffic direction. The gateway governs north-south traffic — clients entering the system. A service mesh governs east-west traffic — services talking to each other inside, via sidecars handling mTLS, retries, and routing. Large systems run both; small ones usually need neither the mesh nor, sometimes, the gateway.'
  - question: 'What is the Backend-for-Frontend (BFF) pattern?'
    answer: 'A gateway variation: instead of one gateway serving every client, each client type — web, mobile, partner — gets its own thin gateway shaping responses for its needs. It resolves the tug-of-war where one generic API serves everyone poorly, at the cost of more deployables. The BFF is the gateway pattern admitting that clients differ.'
  - question: 'Is an API gateway a single point of failure?'
    answer: 'Architecturally yes — everything passes through it — which is why production gateways run as clustered, horizontally scaled fleets behind a load balancer, with health checks and failover. The mitigation is standard; the sin is running the everything-door as a single instance because it worked fine in staging.'
  - question: 'Does an API gateway add latency?'
    answer: 'One hop, typically single-digit milliseconds — and often a net win: aggregation collapses multiple client round trips into one, caching answers repeats at the edge, and connection reuse to backends is faster than cold client connections. The honest accounting compares the hop against the round trips and duplicated policy code it eliminates.'
  - question: 'When do you NOT need an API gateway?'
    answer: 'More often than vendors say: a single service with one client type, a server-rendered app calling its own backend, internal APIs behind a VPN, or anywhere an existing reverse proxy already covers TLS and routing. A gateway earns its operational cost when there are many services, many clients, or real policy to centralize — not before.'
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: 'The front door, already built'
  text: 'Back4app puts a managed gateway in front of every app: authentication, rate limits, routing to auto-generated APIs and Cloud Code — enforced at the platform edge with zero gateway infrastructure for you to deploy or scale.'
  linkText: 'Start Free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-27'
translationKey: api-gateway-architecture
---

**An API gateway is a managed front door for your APIs — one entry point that routes, authenticates, and rate-limits every request.** The idea is centralization: the cross-cutting work every endpoint needs (who are you, how fast may you call, where does this go, what happened) moves out of N services and into one policy layer that clients can't walk around.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | One entry point: route, authenticate, limit, transform, observe |
| vs. load balancer | LB picks an instance; gateway makes API-aware policy decisions |
| vs. reverse proxy | A gateway *is* one — with an API policy brain attached |
| vs. service mesh | Gateway = north-south (clients in); mesh = east-west (service to service) |
| The honest question | Whether you need one at all — many systems don't yet |

## What the front door does

A gateway's job list, as configuration rather than N copies of middleware — a typical declarative route:

```yaml
# gateway route: one entry, policy attached
route: /orders/**
  service: orders-api:8080          # routing — topology stays private
  auth: bearer-jwt                  # authentication at the door
  rate_limit: 100/min per key       # budgets before backends
  transform:
    strip_headers: [X-Internal-*]   # translate between edge and inside
  timeout: 5s
  observe: log + trace + metrics    # one place to watch everything
```

From the client's side, a managed gateway disappears into the SDK — one call, with the door's checks applied before any code of yours runs:

**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")
}
```

## The four look-alikes, separated

| | Reverse proxy | Load balancer | **API gateway** | Service mesh |
| --- | --- | --- | --- | --- |
| Question answered | "Forward this inward" | "Which instance?" | **"Which service, may you, how fast?"** | "How do services talk safely?" |
| Traffic | North-south | North-south | **North-south** | East-west |
| Decision basis | Host/path | Health + algorithm | **API policy: auth, limits, shape** | Service identity |
| Typical layer | L7 basic | L4/L7 | **L7, API-aware** | Sidecars everywhere |
| Relationship | Gateway's parent class | Usually in front of the gateway | — | Coexists behind it |

```mermaid
flowchart LR
  accTitle: API gateway architecture
  accDescr: Web, mobile, and partner clients send requests to a load balancer fronting a clustered API gateway, which authenticates, rate limits, and routes to internal services; the services and their topology stay private behind it.
  W["Web"] --> LB["Load balancer"]
  M["Mobile"] --> LB
  P["Partners"] --> LB
  LB --> G["API gateway (clustered)<br/>auth · limits · routing ·<br/>transform · observe"]
  G --> S1["Orders service"]
  G --> S2["Users service"]
  G --> S3["Search service"]
```

The [canonical pattern description](https://microservices.io/patterns/apigateway.html) adds the variation worth knowing: the **[Backend-for-Frontend](https://samnewman.io/patterns/architectural/bff/)** — one thin gateway *per client type*, each shaping responses for its client — which trades deployables for the end of one-size-fits-none APIs.

## The drawbacks, stated plainly

The gateway centralizes power, and centralization bills you four ways. **Single point of failure:** everything flows through it — run it clustered behind a load balancer or accept that its outage is *the* outage. **The new bottleneck:** every feature team now files config changes against one shared component; governance and self-service tooling are part of adoption, not extras. **The monolith reborn:** aggregation logic accumulating in the gateway quietly rebuilds the centralized app you decomposed — keep it policy-thick and logic-thin. **Config sprawl:** hundreds of routes with per-route policies is a codebase; review it like one. None of these argue against gateways; all of them argue against casual ones.

## Common use cases

- **Microservices front doors** — the origin story: many services, one coherent API, topology free to evolve behind it.
- **Multi-client products** — web, mobile, and partners with different auth, shapes, and limits — the BFF's home turf.
- **API monetization** — keys, plans, quotas, and usage metering enforced at one point.
- **Migrations** — the strangler pattern: the gateway routes old paths to the legacy system and new paths to its replacement, invisibly.
- **Edge policy** — CORS, TLS, header hygiene, and [rate limiting](/glossary/api-rate-limiting-throttling/) applied once instead of N times.

## Do you need one? A decision matrix

| A gateway earns its keep when… | Skip (or defer) it when… |
| --- | --- |
| Many services sit behind one API | One service serves one client type |
| Clients differ in auth, shape, or limits | A reverse proxy already covers TLS + routing |
| Policy must be enforced centrally | Policy is a middleware import away |
| Topology changes faster than clients | The topology is one box |
| Someone owns the gateway as a product | Nobody would operate it |

The unowned answer on most comparison pages: **not yet** is a legitimate architecture. Add the door when there's a building behind it.

## Limitations and trade-offs

- **Availability is now the gateway's availability.** Cluster it, health-check it, and rehearse its failure — the mitigation is standard and non-optional.
- **One hop of latency, honestly netted** against the round trips and duplicated middleware it removes; measure, don't assume either way.
- **Aggregation is a slope.** Composing responses is legitimate; business logic in the gateway is the ESB pattern wearing a new badge.
- **Open-source options carry ops.** Excellent gateways exist as open source (Envoy-based stacks and peers) — each a distributed system you now run, upgrade, and secure.
- **Managed gateways trade control for silence.** The platform-operated door is the right answer exactly when gateway ops would be undifferentiated toil.

## The gateway on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The gateway layer comes with the platform: every request — REST, GraphQL, SDK, or Cloud Code call, as in the code tabs above — enters through a managed edge that authenticates sessions and keys, applies per-app rate limits, and routes to the generated APIs or your functions, with the platform operating the clustering and scaling that make a front door safe. The decision matrix collapses: you get the gateway's guarantees on day one, and skip owning the door entirely.