API Gateway
The API Gateway is a single managed entry point for a microservices system. It routes requests, aggregates responses, and centralizes cross-cutting concerns such as auth, rate limiting, and observability.
An API Gateway is a server that sits between external clients and a set of backend services. Instead of letting clients call dozens of microservices directly, every request enters through the gateway, which routes it to the correct service and returns the response. It is the canonical front door for a microservices system.
The problem it solves is coupling. When clients call services directly, they must know each service's address, protocol, and authentication scheme. Service boundaries leak to the client, and refactoring the backend breaks consumers. A gateway hides that topology behind a stable, unified interface.
How It Works
The gateway terminates inbound connections (usually HTTPS) and inspects each request. Using a route table, it maps a path or host to an upstream service. Along the way it applies cross-cutting concerns: authentication and authorization, rate limiting, request and response transformation, caching, and observability. It may also aggregate several backend calls into one response.
Gateways are typically deployed as a horizontally scaled, stateless tier behind a load balancer. Popular implementations include Kong, NGINX, Envoy, AWS API Gateway, Azure API Management, and Spring Cloud Gateway.
Modern gateways are configuration-driven and support plugins or filters, so new behavior can be added without writing a service from scratch. They commonly integrate with an identity provider for OAuth2 and OpenID Connect, expose metrics for every route, and support hot reloading of routes so the topology can change without downtime.
When to Use It
Use an API Gateway when you have multiple services and multiple client types, or when cross-cutting concerns such as auth and rate limiting would otherwise be duplicated in every service. It is also valuable when you want to evolve the backend without forcing clients to change.
For a single service or a small system, a gateway can be unnecessary overhead. Direct calls or a plain load balancer may be enough.
Trade-offs
The gateway centralizes logic, which keeps services thin but creates a potential single point of failure and a possible bottleneck. It must be made highly available and scaled carefully. There is also a risk of the gateway becoming a bloated, god-like component if too much business logic accumulates in it; keep it focused on routing and cross-cutting concerns. Operationally it adds a network hop and one more system to deploy, monitor, and secure.
Related Patterns
When different clients need different aggregations, the Backend for Frontend pattern provides a gateway per client type. Gateway Routing, Gateway Aggregation, and Gateway Offloading describe specific responsibilities a gateway takes on. A service mesh handles service-to-service traffic, complementing the north-south role of the gateway.
Example
A retail platform exposes catalog, cart, pricing, and orders services. A mobile app should not call four hosts with four tokens. Instead it calls https://api.shop.com. The gateway validates the JWT, enforces a per-user rate limit, routes /catalog/* to the catalog service and /orders/* to the orders service, and adds a trace header. The mobile team sees one consistent API while the platform team is free to split or merge services behind it.