API Gateways

The front door of your system: routing, authentication, rate limiting, and request shaping — and how gateways differ from plain reverse proxies.

Intermediate · 15 min read

Why this matters

The moment you have more than a couple of services, clients face an annoying question: who do I talk to? Dozens of service addresses, each with its own auth scheme, its own rate limits, its own quirks. An API gateway answers by being the single front door: one address, one auth story, one place where cross-cutting concerns live. Every request passes through it; every service behind it stays focused on business logic instead of reinventing TLS termination for the ninth time.

Think of a hotel front desk. Guests don't wander the halls knocking on the kitchen, housekeeping, and accounting doors. They talk to the concierge, who routes each request to the right department, verifies who's asking, and handles the boring-but-critical stuff (keys, billing, wake-up calls). Your API gateway is the concierge; your microservices are the departments happily ignoring the lobby chaos.

Video: What is an API Gateway? — IBM Technology
IBM's primer shows where a gateway earns its keep in a microservices setup.

Gateway vs. reverse proxy vs. load balancer

These get conflated constantly, so let's be precise:

flowchart LR
    C[Clients] --> G[API Gateway<br/>auth • rate limits • routing]
    G --> S1[orders service]
    G --> S2[users service]
    G --> S3[search service]
    G --> S4[legacy monolith]

The line is blurry — a reverse proxy with enough plugins becomes a gateway — but the intent differs: a gateway owns the API contract with the outside world.

Video: What is API Gateway? — ByteByteGo
Lines up gateways, reverse proxies, load balancers, and BFFs side by side.

What lives in the gateway

Authentication & authorization. The gateway validates tokens (JWTs, API keys, OAuth flows) once, then forwards the request with the caller's identity attached — often as headers the inner services trust. Your eleven microservices never each implement "is this token expired" again. (Famous last words, but it's the goal.)

Rate limiting & quotas. Per-API-key or per-user throttles live naturally here — it's the one place that sees all traffic. Stripe-style tiered quotas ("10,000 requests/day on the free tier") are a gateway config, not application code. (See Rate Limiting for the algorithms.)

Request shaping. The gateway translates between the outside world's needs and your services' reality: REST in, gRPC out; aggregating three service calls into one client response (reducing chatty mobile round trips); stripping internal fields you never meant to expose. (That last one has caused real CVEs. The gateway is your last line of defense against accidentally serializing is_admin.)

sequenceDiagram
    participant M as Mobile app
    participant G as API Gateway
    participant O as orders svc
    participant U as users svc

    M->>G: GET /dashboard (1 request, 1 token)
    G->>G: Validate JWT, check quota
    G->>O: GET /orders?user=7
    G->>U: GET /users/7
    O-->>G: orders
    U-->>G: profile
    G-->>M: Combined dashboard payload

Observability. One choke point means one place to log every request, measure latency percentiles, and trace calls across services. When the 3 AM page arrives, the gateway's dashboards are where you start.

Video: The API Gateway Pattern: When Your Microservices Need a Traffic Cop — System Design Lab
Covers routing, auth, rate limiting, and aggregation — the gateway's daily jobs.

The BFF pattern

One gateway rarely fits all clients. A mobile app wants tiny, aggregated payloads; a web app wants something richer; partner integrations want stability above all. The Backend for Frontend (BFF) pattern gives each client type its own gateway layer, each optimized for that client's needs — all fronting the same services. It's more gateways to run, but each one is simpler and changes for the right reasons.

flowchart LR
    Web[Web app] --> B1[BFF: web]
    Mobile[Mobile app] --> B2[BFF: mobile]
    Partner[Partners] --> B3[BFF: partner API]
    B1 --> S[Shared services]
    B2 --> S
    B3 --> S

Video: "Backends for Frontends": what is it? — Software Developer Diaries
One concierge per client: why mobile, web, and TV each deserve their own tailor-made backend.

The honest trade-offs

A gateway is a single point of control and therefore a single point of failure. If it goes down, everything behind it is unreachable — so it must be deployed redundantly across zones, with health checks and fast failover. It also adds latency (one more hop, usually single-digit milliseconds) and can become a bottleneck of ownership: when every team needs a route change and one platform team owns the gateway config, you've built a very expensive ticket queue. Good gateway platforms solve this with self-service config and GitOps workflows.

There's also a philosophical split: centralized gateways (one team, one config) vs. sidecar/decentralized approaches where each service owns its edge via something like Envoy. Large orgs often end up with both — a thin edge gateway for auth and DDoS protection, plus per-service sidecars for fine-grained policy.

Video: The API Gateway - Software Architecture — The Software Mentor
Weighs when a gateway helps against its cost and single-point-of-failure risk.

Takeaways

  1. A gateway is the single front door: one address, one auth story, one home for cross-cutting concerns.
  2. Auth, rate limiting, request shaping, and observability belong in the gateway — not reimplemented in every service.
  3. The BFF pattern tailors the edge per client type instead of forcing one contract on everyone.
  4. It's a single point of failure and a potential ownership bottleneck — deploy it redundantly and make its config self-service.

Check your understanding

  1. How does an API gateway differ from a plain load balancer?

    • A load balancer distributes traffic across instances of the same service; a gateway routes between different services and adds auth, rate limiting, and request shaping
    • There is no difference — the terms are interchangeable
    • A gateway replaces the need for DNS
    • A gateway only works with HTTP/2

  2. In the gateway pattern, where is a client's JWT typically validated?

    • In each microservice independently
    • In the database, via a stored procedure
    • Once at the gateway, which forwards the caller's identity to inner services
    • By the client itself before sending the request

  3. What is the BFF (Backend for Frontend) pattern?

    • Running the backend and frontend in the same process
    • Giving each client type (web, mobile, partners) its own tailored gateway layer over shared services
    • A database replication strategy
    • A testing strategy where backends test frontends

  4. What is the main availability risk of an API gateway?

    • It makes individual services slower to deploy
    • It forces all services to use the same programming language
    • It prevents the use of caching
    • It is a single point of failure — if it goes down, everything behind it is unreachable

Go deeper

Want to keep pulling this thread? These talks and tutorials go further than we did here:

Sources & further reading