The API Gateway Pattern

External clients should not need to know about every internal microservice. An API Gateway sits at the edge as a single entry point — routing /users to the User Service, /orders to the Order Service, and /payments to the Payment Service. It centralizes cross-cutting concerns: authentication, rate limiting, request logging, SSL termination, and response aggregation.

Without a gateway, clients hold URLs for five services, each with its own auth mechanism and error format. With a gateway, clients talk to one host and one API contract. The gateway can also implement the Backend for Frontend (BFF) pattern — exposing different aggregated endpoints for mobile vs web clients.

Security boundary: terminate TLS at the gateway (or mesh), authenticate/authorize at the edge, and prefer mTLS or workload identity for service-to-service calls inside the perimeter — do not leave internal HTTP open without a trust model.

Before

Client talks to every service directly

1const user   = await fetch('https://users.internal/api/me');2const orders = await fetch('https://orders.internal/api/mine');3const cart   = await fetch('https://cart.internal/api/items');4// Three hosts, three auth tokens, three failure modes

After

Client talks to one gateway

1const dashboard = await fetch(2  'https://api.example.com/v1/dashboard',3  { headers: { Authorization: `Bearer ${token}` } }4);5// Gateway aggregates user + orders + cart server-side

Check your understanding

What cross-cutting concerns often live at the gateway?Show answerHide answer
Answer
AuthN/authZ checks, rate limiting, TLS termination, logging, and sometimes response aggregation.
Why keep internal service URLs off public clients?Show answerHide answer
Answer
One front door reduces attack surface and lets you change topology without rewriting every client.
What is a BFF?Show answerHide answer
Answer
Backend for Frontend — gateway/API shaped for a specific client (mobile vs web) rather than one-size-fits-all.