Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

API Gateway

When an application is split into many services, exposing each of them directly to clients pushes the cost of the split onto every caller. A client then has to know each service’s address, make one round trip per service to assemble a single screen, and be changed whenever a service is split, merged or renamed.

An API gateway is a single entry point placed in front of those services. It routes each request to the service that owns it, and where a client needs data from several services it can compose the internal calls into one response. Because every request passes through it, it is also the natural home for concerns that would otherwise be reimplemented in each service:

  • TLS termination and certificate management
  • Authentication and token validation, so services receive an already-verified principal
  • Rate limiting and request quotas
  • Request and response logging, correlation IDs and metrics
  • Protocol translation between an external HTTP API and internal messaging or gRPC

The standing risk is that the gateway grows into a shared monolith. Business rules drift into it because it is the one component that sees everything, and once several teams depend on it, deploying the gateway becomes a coordination exercise rather than a routine release. Keep it to routing, composition and cross-cutting concerns, and keep domain logic behind it in the service that owns the data.

Backends for frontends

Section titled “Backends for frontends”

Where client types differ enough that one API cannot serve them all — a mobile client wants fewer, coarser responses than a desktop web client, and pays more for each round trip — the pattern is applied once per client type instead of once per system. Each client gets its own gateway, owned by the team that owns that client, so a change made for the mobile app cannot destabilise the web app.

Further reading

Section titled “Further reading”