Advantages of API Gateway Pattern

An API gateway earns its keep because it is a single reverse proxy at the network edge that terminates every client connection and runs each request through one ordered filter chain — authenticate, rate-limit, route, transform, fan-out, aggregate — so that cross-cutting work and multi-service round trips happen once, in the datacenter, close to the services, instead of N times over the client's slow, untrusted link.

Almost every "advantage" you see listed (central auth, rate limiting, caching, aggregation, version routing, request/response transformation, centralized logging, partial-failure handling, client-specific responses) is a specific filter hung on that one chain. They are not fifteen separate features; they are the consequences of one architectural move: relocating the edge. Two consequences are worth separating because they drive different designs:

• Concern consolidation (the edge move). TLS termination, JWT validation, rate limiting, WAF rules, and access logging are written and deployed once at the gateway instead of copied into every service. A service behind the gateway can treat traffic as already authenticated and rate-limited at the edge, but only if it also verifies that the request really came from the gateway — for example via mTLS or a signed service token.
• Request/response shaping (the composition move). Because the gateway sits between the client and the fleet, it can turn one client call into several backend calls (fan-out), merge the results (aggregation), degrade gracefully when one backend fails (partial-failure handling), and hand each client type the shape it wants. This is what turns a chatty mobile screen into a single round trip.

The rest of this page traces one real request through that chain, then is blunt about the cost — because the same centralization that buys you these wins is exactly what can sink a system.

A traced request: mobile product page

A mobile app opens the page for product 8842. That screen needs data from four services: catalog (name, images), pricing (personalized price for user 4471), inventory (in-stock?), and reviews (top 3). The device is on cellular with a ~100 ms round-trip; the services sit in one datacenter with ~2 ms intra-DC latency. Here is the single request GET /mobile/product/8842 with header Authorization: Bearer eyJhbGc… moving through the chain:

Why it matters, with numbers. Contrast the two ways to build this screen:

The saving is not raw milliseconds if the four direct calls were perfectly parallel — it is the number of expensive edge round trips (each with TLS setup and radio cost on mobile), the elimination of client-side orchestration, and moving partial-failure logic to a place that can actually enforce a shared deadline. That is the composition move paying off.

Pitfalls

• The god-gateway / distributed monolith. Aggregation logic invites business logic. Once discount rules or eligibility checks live in the gateway, it becomes a shared component that every team must edit and redeploy — a monolith wearing a proxy costume. Keep the gateway to routing, auth, and mechanical composition; business rules belong in services.
• Single point of failure and total blast radius. Every request flows through it, so the gateway is your availability ceiling. It must be horizontally scaled, health-checked, and deployed with care; a bad config push takes down all APIs at once, not one service.
• The latency and CPU tax. You added a network hop plus per-request filter CPU (JWT verification, JSON re-serialization for transforms) to every call. On hot internal paths this p99 tax is real; measure it.
• Fan-out amplification. Composition hides an N+1 problem: one client call can become dozens of backend calls, and one slow backend stalls the whole response unless every fan-out call has its own bounded timeout and the aggregate has a hard deadline (as in step 5 above). Without those budgets, the gateway turns a single slow service into a system-wide stall: a stalled fan-out holds the gateway worker and its upstream connection, enough of them saturate the pool, and unrelated routes — a perfectly healthy /checkout — start returning 503s. The slow service's blast radius jumps the fence.
• Team bottleneck. A single shared gateway means one config, often owned by one team. Every service that needs a new route or transform queues behind that team's review — the organizational reason the BFF variant exists.
• Schema coupling. Response aggregation forces the gateway to know each backend's payload shape. Backend schema changes now ripple into gateway code, re-coupling things you split apart.
• Trusting the network behind the gateway. A service that assumes “anything from inside the datacenter is safe” can be called directly, bypassing auth and rate limits. Enforce mTLS or signed service tokens between the gateway and backends so services can verify the request really came through the edge.

When to use it — and when not to

Reach for a gateway when the concrete signals line up: you expose a public north-south edge (untrusted clients hitting the system from outside), you have more than one client type (mobile + web + partners) with different data-shape needs, cross-cutting concerns (auth, TLS, rate limiting, WAF, quota) are being copy-pasted into every service, and chatty clients would otherwise make many round trips you could aggregate. If two or more of those hold, the edge move pays for its hop.

Skip it — or scope it narrowly — when none do: a single client talking to a handful of internal services should just call them directly; adding a gateway there buys indirection and a failure point for nothing.

Trade-offs versus the alternatives

• Direct client-to-service. Gain: no hop, no extra infra, simplest. Cost: the client couples to service topology and locations, auth is duplicated everywhere, no aggregation, and every client re-implements retries and fallbacks. Choose this when traffic is internal and the service count is small.
• Service mesh (Istio, Linkerd, Envoy sidecars). A mesh solves cross-cutting concerns for east-west (service-to-service) traffic — mTLS, retries, load balancing, telemetry — transparently at every hop, with no central choke point. But it is infrastructure, not a client-facing API surface, and it does not aggregate or reshape responses for external clients. Choose the mesh when your concern is internal resilience and observability; the two are complementary — gateway at the north-south edge, mesh for east-west — and large systems run both.
• Backend-for-Frontend (BFF). One small gateway per client type instead of one shared gateway. Gain: each client team owns and ships its own edge, killing the shared-team bottleneck and letting responses be tailored aggressively. Cost: duplicated edge plumbing (auth, TLS) across BFFs and more deployables to run. Choose BFF when a single gateway has become a coordination bottleneck or client needs have diverged sharply.

Crisp rule: choose a shared API gateway when you have a public, multi-client north-south edge with common cross-cutting needs; prefer a service mesh when the problem is service-to-service resilience; prefer a BFF when one gateway has turned into a team bottleneck.

Takeaways

• The gateway's advantages all descend from one move — relocating the edge — split into concern consolidation (auth/TLS/rate-limit written once) and request shaping (fan-out, aggregation, graceful degradation). Understand the two mechanisms and the fifteen bullets collapse.
• Aggregation's win on mobile is fewer expensive client round trips and server-side deadline enforcement, not raw compute saved — quantify it before assuming it.
• The same centralization that buys you those wins is your failure ceiling, latency tax, and organizational bottleneck. Bound every fan-out call, keep business logic out, and scale the gateway for HA.
• It is a north-south tool. For east-west resilience use a service mesh; when one gateway becomes a bottleneck, split into BFFs.

Re-authored and deepened for this guide. Sources: Chris Richardson, Microservices Patterns (Manning, 2018), ch. 8 — API Gateway and Backend-for-Frontend; Sam Newman, Building Microservices, 2nd ed. (O'Reilly, 2021); Phil Calçado / SoundCloud and Thoughtworks writing on the BFF pattern; Netflix Zuul and Envoy/Kong gateway documentation on filter chains, rate limiting, and aggregation; Istio and Linkerd docs on east-west service-mesh concerns.