API Gateways: What They Do and When You Need One
An API gateway is a server that sits between clients and backend services, acting as the single entry point through which all API traffic passes. Every request goes through the gateway, which can inspect, modify, authenticate, route, transform, and rate-limit that traffic before it reaches any backend service. For teams running multiple services, an API gateway centralizes concerns that would otherwise be duplicated across every service independently.
Understanding what a gateway provides — and what it does not — is the prerequisite to deciding whether one belongs in your architecture.
What an API Gateway Does
The core function is routing. The gateway receives incoming requests and forwards them to the appropriate backend service based on path, headers, or other request attributes. A request to /api/users routes to the user service; a request to /api/orders routes to the order service; a request to /api/search routes to the search service. Clients interact with a single endpoint; the routing complexity is hidden behind the gateway.
Authentication and authorization are the most valuable gateway capabilities for teams with multiple services. Instead of implementing authentication in every service — verifying tokens, checking scopes, handling expired credentials — you implement it once at the gateway. The gateway verifies the request before it reaches any backend service, and can pass verified identity information (user ID, permissions) to backend services via request headers. Services trust the gateway rather than re-validating credentials themselves.
Rate limiting at the gateway applies uniformly across all services without requiring each service to implement its own rate limiting infrastructure. A burst of requests from a misbehaving client is caught at the gateway, before it generates load on any backend service.
SSL/TLS termination at the gateway means backend services can communicate over HTTP on an internal network, simplifying their configuration. The gateway handles certificate management; services are not concerned with it.
Request and response transformation allows the gateway to translate between what clients expect and what backend services provide. API versioning can be implemented at the gateway by routing /v1/ requests to older service versions and /v2/ requests to newer ones, without requiring version logic inside the services. Response transformation can merge fields from multiple services into a single response, presenting a unified API to clients regardless of how the backend is decomposed.
Logging and observability are naturally centralized at a gateway. Every request passing through generates a log entry with timing, status codes, and routing information. This provides a complete picture of API traffic without instrumenting every service independently.
When a Gateway Becomes Necessary
For a single-service architecture with one backend, a gateway adds complexity without proportional benefit. Standard web server middleware handles most gateway concerns — authentication, rate limiting, logging — at lower operational cost.
The inflection point is typically when you have multiple services that external clients need to access through a unified interface, or when you are enforcing common policies (authentication, rate limiting, SSL termination) that would otherwise be duplicated across services.
Gateways become particularly valuable in these conditions: multiple teams maintaining different services that need consistent authentication enforcement; a public API surface that must remain stable while the internal service decomposition evolves; regulatory requirements around logging and audit trails that must cover all traffic; significant variation in traffic requiring sophisticated routing or canary deployments.
What a Gateway Cannot Replace
A gateway handles cross-cutting concerns at the edge. It cannot replace the business logic, data validation, and error handling that belong inside each service. Services behind a gateway still need their own input validation — trusting the gateway to have done it is a single point of failure. Services still need their own error handling and graceful degradation. The gateway protects against traffic-level abuse; it does not protect against logic-level failures inside services.
A gateway also does not eliminate the complexity of a microservices architecture — it centralizes some of it. Service discovery, inter-service communication, distributed tracing, and the operational overhead of running multiple services are not gateway problems. If you are considering a gateway because your multi-service architecture is difficult to manage, the gateway may relieve some specific pain points while leaving others untouched.
Popular Options
Kong, AWS API Gateway, Azure API Management, Nginx, and Traefik are the commonly deployed options, spanning self-hosted and managed variants with different tradeoff profiles on cost, configurability, and operational burden.
Kong is a popular open-source gateway with extensive plugin support, deployable on-premises or in the cloud. AWS API Gateway and Azure API Management are managed services that eliminate infrastructure management but bind you to a cloud provider’s pricing and feature set. Nginx can function as a gateway with appropriate configuration and is often the right choice for simpler routing-and-SSL-termination use cases without needing full gateway features.
The decision between self-hosted and managed is primarily an operational one. Managed gateways charge per request and require no server management. Self-hosted gateways require infrastructure management but have no per-request cost at scale. For teams with high request volume and operational capacity, self-hosted becomes more economical. For smaller teams or early-stage products, managed eliminates undifferentiated infrastructure work.
The Gateway as Architectural Bet
A gateway is an architectural commitment. Moving traffic through it means it is a potential single point of failure if not deployed with redundancy, a potential bottleneck if not sized appropriately, and a potential source of latency if not optimized. These are manageable concerns, not disqualifying ones, but they require intentional architecture rather than the assumption that adding a gateway is purely additive.
The value proposition is real: centralized authentication, rate limiting, observability, and routing eliminate duplicated work across services and enforce consistent policy. For multi-service architectures, the question is not usually whether to use a gateway, but which one and how to scope what it does. A gateway that does too much becomes a bottleneck for all service development; a gateway scoped to infrastructure concerns (auth, routing, SSL, rate limiting) is an enabler.