5 min read

API Gateway

One front door that handles the boring parts of every request so services don't each reinvent them.

The story

A mobile app talks straight to six backend services: users, catalog, cart, orders, payments, notifications. Each one has its own public hostname, which is hard-coded in the app.

Each team wrote its own token check. Five of them check the token's expiry. The orders team's check doesn't, so a token stolen last month still works there. The security review finds it, and so do several other things:

  • Rate limiting exists on two services out of six.
  • Renaming cart-api.example.com needs an app-store release and waiting months for old app versions to die out.
  • The home screen makes five round trips over a mobile network to draw one page.
  • No one can answer "how many requests per second do we get?" because the logs are in six different formats.

None of these are business problems. They're cross-cutting concerns: things every request needs, written six times, six slightly different ways. An API gateway puts them in one place.

The idea

Clients know one hostname. Behind it you can rename, split, merge or move services and no client ever notices.

What a gateway does to every request, in order

Steps 1–6 are written and tested once. Services receive a request that's already authenticated and trust the X-User-Id header, because only the gateway can reach them.

The usual jobs:

JobWhat it means
RoutingPath or host → service. /v1/orders/* goes to orders.
AuthenticationValidate the token once. Services get a trusted user ID.
Rate limitingPer key, per user, per endpoint, enforced in one place.
TLS terminationCertificates live in one place, not on every service.
Versioning and transformationKeep /v1 alive while services move to a new shape.
AggregationOne client call fans out to three services, and the gateway merges the results.
ObservabilityOne access log, one set of latency and error metrics for all traffic.
Traffic controlCanary 5% to a new version, retries, timeouts, circuit breaking.

Gateway, load balancer, service mesh, BFF

These four get mixed up. Where they sit tells them apart:

  • Load balancer: spreads traffic across identical copies. Layer 4 or simple layer 7. Usually sits in front of the gateway too, since the gateway itself runs as several instances.
  • API gateway: traffic coming into the system from outside (north-south). Knows about users, keys and routes.
  • Service mesh (Istio, Linkerd): traffic between services inside the system (east-west), via a sidecar next to each one.
  • BFF: a thin layer per client type (mobile, web) that builds exactly the response that client's screens need. It fixes the five-round-trips problem from the story.

Products: Kong, AWS API Gateway, Apigee, Envoy and NGINX configured as gateways, Traefik.

The trade-offs

What it costs

  • One more hop. Usually about a millisecond inside a data centre, plus whatever plugins you add.
  • A single point of failure if you run it badly. Run several instances across zones behind a load balancer, and keep its config in version control.
  • A team bottleneck. If every route change needs a ticket to the "gateway team", you've rebuilt the monolith's release queue. Let service teams own their routes through config.
  • Logic creep. Once there's a convenient central place, people start putting "just this one check" there. Then pricing rules, then feature flags. A gateway that knows business logic is a monolith nobody planned.

When you don't need one: a single backend (a monolith) behind a load balancer already has one front door, so a gateway adds a hop and little else. Most frameworks' middleware covers auth and rate limiting there.

Cheat sheet

QuestionAnswer
What problem does it solve?Cross-cutting concerns written N times, and clients coupled to internal service layout
Must-have jobsRouting, auth, rate limiting, TLS, logging
Never put in itBusiness rules, database access, anything that depends on one service's data
AvailabilitySeveral instances, several zones, behind an L4 load balancer
Latency cost~1 ms per hop plus plugins. Measure it.
North-south vs east-westGateway = into the system. Service mesh = between services.
Multiple client types?Add a BFF per client behind the gateway
Monolith?Probably skip it. Load balancer plus middleware is enough.

Say it in the interview

"Clients hit one API gateway that terminates TLS, validates the JWT, rate-limits per API key and routes by path, so services get a trusted user ID and never implement auth themselves. It runs as several instances across zones behind a load balancer. Business logic stays in the services, and the gateway only does what every request needs."

Go deeper

← PreviousThe Database Scaling LadderNext →Monolith vs Microservices