An API gateway is a server that sits in front of a collection of backend services and acts as the single entry point for all clients. Chris Richardson’s microservices.io catalog defines the API Gateway pattern as the answer to a problem created by microservices: if a client had to call dozens of fine-grained services directly, it would face chattiness, tight coupling to the internal decomposition, and a tangle of protocols. The gateway hides that internal structure behind one cohesive interface.
According to the pattern, the gateway is “the single entry point for all clients.” Some requests are “simply proxied/routed to the appropriate service,” while others are handled by “fanning out to multiple services.” This second behavior, request aggregation, “enables clients to retrieve data from multiple services with a single round-trip,” reducing the number of network round-trips and moving the logic for orchestrating multiple service calls out of the client and into the gateway.
The gateway is also the natural place to enforce cross-cutting concerns. The pattern notes it “might also implement security, e.g. verify that the client is authorized to perform the request,” and can “authenticate the user and pass an Access Token containing information about the user to the services.” Centralizing authentication, authorization, rate limiting, TLS termination, and request logging at the edge means individual services do not each have to reimplement them.
Production API gateways turn this pattern into infrastructure. Products such as Kong, AWS API Gateway, and NGINX-based gateways provide configurable routing, authentication plugins, rate limiting, request and response transformation, and observability, so that adding a new policy is a matter of configuration rather than code in every service. The gateway becomes a control point where operators can shape and protect all inbound traffic.
The pattern carries trade-offs the catalog is explicit about. A gateway is one more component to develop, deploy, and operate, and it can become a development bottleneck if every team must route changes through a single shared gateway. The Backend for Frontend variation addresses this by giving each kind of client its own gateway, aligned with the team that owns that client.