API Gateway
A managed entry point that routes, secures, and monitors API traffic.
Last reviewed: July 25, 2026
What is an API Gateway?
An API gateway sits in front of one or more backend services and acts as a single front door for clients. Instead of calling many microservices directly, clients call the gateway, which handles routing, authentication, rate limiting, and request transformation.
Why teams use it
- Centralized security — validate tokens, API keys, and TLS in one place
- Routing — map
/users/*to the user service and/orders/*to the order service - Observability — consistent logging and metrics for all API traffic
- Versioning — expose
/v1and/v2without changing every backend
Common features
| Feature | Purpose |
|---|---|
| Rate limiting | Prevent abuse and protect backends |
| Request/response mapping | Adapt legacy APIs to modern clients |
| Caching | Reduce load on downstream services |
| WAF integration | Block common web attacks at the edge |
API Gateway vs load balancer
A load balancer distributes traffic across servers but typically operates at Layer 4 or 7 without deep API semantics. An API gateway adds API-specific policies: OAuth scopes, quotas, schema validation, and developer portals.
Examples in the wild
Managed offerings include AWS API Gateway, Azure API Management, Google Apigee, Kong, and Traefik. Teams often place a gateway behind a CDN or WAF for defense in depth.
Cost reality
Managed gateways bill per million requests, which is negligible at startup scale and a real line item at high volume — the point where teams commonly move to Kong/Envoy on their own compute. The subtler cost is latency: every gateway feature (auth calls, transformations, logging) adds milliseconds to every request; audit the plugin chain before blaming backends.
What people get wrong
- A gateway for one internal service. A reverse proxy with auth middleware is simpler and cheaper; gateways earn their complexity with many services or external consumers.
- Business logic creeping into gateway config. Request transformations slowly become an unversioned, untested application layer; keep the gateway to policy, not logic.
- Rate limiting only at the front door. Internal consumers can still stampede a downstream service; per-service limits matter too.
See the full comparison in API Gateway vs Load Balancer vs Reverse Proxy.
Common API Gateway Responsibilities
Beyond simple request routing, an API gateway typically centralizes several cross-cutting concerns that would otherwise need to be duplicated across every backend service: authentication and authorization (verifying API keys or tokens before a request reaches any backend), rate limiting (protecting backend services from being overwhelmed by excessive requests from a single client), request/response transformation (adapting between the format clients expect and what backend services actually provide), and centralized logging and analytics across all API traffic. Centralizing these concerns at the gateway layer means individual backend services can stay focused on their core business logic rather than each reimplementing authentication, rate limiting, and logging independently, which is a major part of why API gateways have become a standard component of microservices architectures specifically.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.