01 The Problem

A company runs three backend services, orders, inventory, and billing, each built by a different team, each exposed directly to the mobile app. Each team implemented its own JWT validation, its own per-client rate limiting, its own request logging, because each service needed all three and nobody wanted to wait on a shared library. Eighteen months later, a security audit finds the orders service still accepts an expired-token grace period nobody meant to keep, the inventory service's rate limiter counts by IP instead of by authenticated client, and the billing service logs full request bodies, credit card fields included, because its logging code predates the other two teams' privacy fixes. Three services, three slightly different, independently drifted implementations of the same three concerns.

Pulling all three into one shared library each service imports fixes the drift, mostly, until the library needs a change that requires every service to redeploy in lockstep, three teams coordinating a release for something that has nothing to do with any of their actual business logic.

An API gateway is the third option: put that shared logic in one place, in front of every service, instead of inside each one. It fixes the drift and the deploy coupling. It also means every request, including ones the gateway does nothing interesting to, now makes an extra hop before it reaches the service that actually handles it, and if that hop goes down, it takes every service behind it down with it.

02 What It Is

An API gateway is a single entry point that every request to a set of backend services passes through, where cross-cutting concerns, auth, rate limiting, logging, request routing, are enforced once, centrally, instead of separately in each service. A request arrives at the gateway, gets authenticated, checked against its rate limit, logged, and routed to whichever backend service actually owns it, which is left free to implement only its own business logic.

The gateway isn't free architecture. It's a new hop in the request path, added latency on every single request, and a new single point of failure: if the gateway is down, every service behind it is unreachable, even services having a perfectly fine day. Consolidating cross-cutting concerns into one place also concentrates the blast radius of a bug there. A bad deploy to the gateway's auth logic doesn't take down one service, it takes down every service behind it at once.

In Plain Terms

An office building with a single reception desk checks every visitor's badge once, at the door, instead of every floor running its own separate check. That's obviously better than eight floors with eight slightly different, occasionally out-of-date visitor policies. It also means if the one reception desk shuts down for any reason, nobody gets into any floor, including the floors that were never the problem.

03 How It Works

Rendering diagram…

04 Trade-offs

	Duplicated per service	Centralized in a gateway
Consistency	Each service's auth, rate limiting, and logging drifts independently; a fix in one doesn't reach the others	One implementation, one fix, applies to every service behind it immediately
Coupling	Each service deploys independently, true isolation	Every service depends on the gateway being correct and available
Failure blast radius	One service's bug affects that service alone	A gateway bug or outage affects every service behind it at once
Latency	Direct request to the service, no extra hop	Every request pays for an extra hop, however small, even ones the gateway does nothing interesting to

05 Where You'll Actually See This

The payment gateway case study is worth a specific clarification here: its "Gateway API" is a single service that owns charges, not an API gateway in this article's sense sitting in front of multiple backend services. Same word, different concept, that case study's gateway is the thing being protected, not the thing doing the protecting.

Rate limiting is one of the concerns this article keeps mentioning in the abstract, and a gateway is usually where it actually lives in practice: one place enforcing the limit for every service behind it, instead of each service tracking its own counters. It's also worth being precise about how this differs from a load balancer: both sit at a similar point in the request path, but a load balancer's job is distributing traffic across identical instances of the same service. A gateway's job is deciding which different service a request even belongs to, on top of auth, rate limiting, and logging along the way. A real system usually has both, a load balancer in front of the gateway's own instances, and the gateway routing to load balancers in front of each backend service.

This whole article assumes multiple backend services already exist behind it. Microservices architecture is where that assumption actually gets argued for, deploy independence traded for network calls and a harder data-ownership question, the same split that made a gateway worth having in the first place.

Worth being precise about which half of "auth" the gateway actually centralizes. Authentication vs authorization covers the distinction: a gateway can validate a token and confirm who's calling for every service behind it, that part generalizes cleanly. Object-level authorization doesn't, because the gateway has no idea which invoice belongs to which caller, only the backend service holding that record does. Centralizing authentication at the gateway is real. Pushing object-level authorization there too is the mistake that article warns about, just at a different layer.

How to reason about it

When asked whether a system needs an API gateway, don't just say "yes, it centralizes cross-cutting concerns." Say what it costs: a new hop on every request, and a new single point of failure for every service behind it. An answer that doesn't weigh that against the drift and duplication of not having one has described what a gateway does, not whether this particular system should have one.

06 Quick Check