API gateways and backends for frontends

What an API gateway does at the edge of a system: routing, authentication, rate limiting, request transformation and aggregation, the backend-for-frontend pattern, GraphQL gateways, and how to keep the gateway from becoming a bottleneck or a monolith.

Reading is half of it. See this used in a real interview: walk through Design a Rate Limiter →

Clients should not need to know that "the app" is forty services. An API gateway is the single entry point that receives every external request, applies the cross-cutting rules, and forwards it to the right service. Almost every architecture diagram in an interview has a box labelled "API gateway"; knowing what goes in it (and what does not) makes that box meaningful.

What a gateway does

• Routing: /orders/* to the order service, /users/* to the user service, by path, host, header or version.
• TLS termination: decrypt once at the edge.
• Authentication: validate tokens or API keys, then pass the verified identity to services in a trusted header. See security and auth.
• Rate limiting and quotas: per user, per API key, per IP. See Design a Rate Limiter.
• Request validation and size limits: reject malformed or oversized requests early.
• Transformation: protocol translation (REST to gRPC), header rewriting, response compression.
• Observability: request ids, access logs, metrics and the root of every trace.
• Resilience: timeouts, circuit breakers, load shedding when backends are overloaded.

Examples: managed gateways (AWS API Gateway, Apigee), Envoy, Kong, NGINX, and edge platforms that run gateway logic close to users.

Aggregation

A mobile home screen may need data from five services. Without help, the phone makes five calls over a slow network. The gateway (or a layer behind it) can aggregate: one client request fans out to services in parallel, and the results are combined into one response. Fewer round trips, smaller payloads, and the internal structure stays hidden. Watch the latency: the response is as slow as the slowest call, so use timeouts and return partial results when an optional part fails. See tail latency.

Backends for frontends (BFF)

Different clients want different shapes: a TV app wants big images and few fields, a phone wants small payloads, a partner API wants stability. A backend for frontend is a thin service per client type that aggregates and shapes responses for that client, owned by the team that builds the client. The generic gateway handles auth and routing; BFFs handle client-specific composition. Netflix popularised the idea. See Design Netflix.

GraphQL as a gateway

A GraphQL gateway lets clients request exactly the fields they need, resolved across services (often with federation, where each service owns part of the schema). It solves over- and under-fetching, but you must guard against expensive queries with depth limits, cost analysis and persisted queries, and caching is harder than with plain GET requests. See API design.

Keeping the gateway healthy

• Stateless and horizontally scaled behind a load balancer, in every zone.
• No business logic: once order rules creep into the gateway, it becomes a shared monolith every team must change and deploy. Keep it to cross-cutting concerns.
• Config as code with reviews and gradual rollout; a bad route rule can take down everything.
• Isolation: separate gateway pools for public, partner and internal traffic, so one cannot starve the others.
• Fast auth: verify signed tokens locally rather than calling an auth service on every request; cache API key lookups.

Gateway, load balancer, mesh

They are often layered: CDN, then load balancer, then gateway, then services connected by a mesh. See load balancing and service discovery and service mesh.

In the interview

Put the gateway in your diagram and say what it does in one line: "terminates TLS, validates the JWT, applies per-user rate limits and routes to services." If the client needs data from several services, mention aggregation or a BFF. If the question is about a public API, mention API keys, quotas and versioning.

Checklist

• Single entry point with TLS, auth, rate limiting and request ids.
• Routing by path or version; services never exposed directly.
• Aggregation or BFFs for chatty clients, with timeouts and partial results.
• No business logic in the gateway.
• Stateless, multi-zone, config changes rolled out safely.