API Gateways

The single front door: routing, auth, rate limits, BFFs, and how a gateway differs from a load balancer.

Once a product is split into many services, clients shouldn't need to know about each of them. An API gateway is the single front door: every external request goes through it, and it routes each one to the right service after handling the concerns that every API shares — authentication, rate limiting, logging. In a microservices design, it's usually the first box after the load balancer.

What a gateway does

Routing: /users/* goes to the user service, /orders/* to the order service. Clients see one host.
Authentication: verify the token or API key once, at the edge, and forward the user's identity to services in a trusted header.
Rate limiting and quotas: per user, per API key, per plan (Rate Limiters).
TLS termination: decrypt HTTPS once, so internal hops stay simple.
Request and response transformation: rename fields, translate REST to gRPC, strip internal headers.
Aggregation: one client call fans out to several services and combines the results.
Observability: request logs, metrics and tracing IDs for every call in one place.
Caching of simple responses, and canary routing that sends a small share of traffic to a new version.

web = client "Web" @0,0.5
mobile = client "Mobile" @0,1.5
lb = service "Load Balancer" @1,1
gw = service "API Gateway\n(auth, rate limit)" @2,1
users = service "User Service" @3,0
orders = service "Order Service" @3,1
search = service "Search Service" @3,2
redis = cache "Redis\n(rate counters)" @2,2
web -> lb
mobile -> lb
lb -> gw
gw -> users, orders, search
gw --> redis

Gateway vs load balancer

They're often confused because they sit in the same place:

In practice you use both: a load balancer spreads traffic across a pool of stateless gateway instances, and the gateway (or a service mesh) spreads traffic across each service's instances. See Load Balancers.

Backend for frontend

Different clients need different shapes of data: the mobile app wants a compact payload in one round trip, the web app wants more. A Backend for Frontend (BFF) is a thin gateway per client type that aggregates and trims responses for that client, instead of one gateway trying to please everyone. GraphQL gateways serve a similar purpose by letting each client ask for exactly the fields it needs.

Pitfalls

Single point of failure: run several stateless instances behind a load balancer, across zones.
Extra latency: one more hop, usually a few milliseconds. Keep the gateway fast — no heavy business logic.
A "god gateway": business rules creeping into the gateway make it a bottleneck that every team has to change. Keep it to cross-cutting concerns.

Products

Managed: AWS API Gateway, Google Apigee, Azure API Management. Self-hosted: Kong, Envoy, NGINX, Apache APISIX. In an interview, the generic "API gateway" box is fine; name a product only if asked.

[!INTERVIEW] Keep it short Don't spend long on the gateway. "Requests go through an API gateway that authenticates the JWT, applies per-user rate limits, and routes to the right service" is usually all an interviewer needs before you move on to the interesting parts.