What an API Gateway Does
Without an API gateway, each microservice is exposed directly to clients. Every service must implement auth, rate limiting, logging, and CORS. Clients must know every service's address. When service addresses change, clients break.
An API gateway centralises all of this:
- Request routing:
/api/users/*→ User Service,/api/orders/*→ Order Service - Authentication: Validate JWT/API key once at the gateway — services trust the gateway
- Rate limiting: Enforce per-client request quotas before traffic reaches services
- SSL termination: Handle HTTPS at the gateway — services communicate internally over HTTP
- Request/response transformation: Translate between JSON and XML, add headers, reshape payloads
- Load balancing: Distribute traffic across service instances
- Logging & analytics: Capture all API traffic in one place
- Caching: Cache responses for expensive or frequently-repeated calls
API Gateway vs Reverse Proxy vs Load Balancer
| Component | Primary Role | API Awareness |
|---|---|---|
| Load Balancer | Distribute traffic across server instances | None — layer 4 (TCP) or basic layer 7 |
| Reverse Proxy (Nginx) | Forward requests, SSL termination, static files | Minimal — path-based routing only |
| API Gateway | Full API management: auth, rate limiting, routing, transform | Full — understands API semantics, keys, versions |
Common API Gateway Features
Authentication & Authorisation
The gateway validates credentials centrally. Options: API key lookup, JWT signature verification, OAuth 2.0 token introspection. Once authenticated, the gateway passes the verified identity (user ID, roles) to downstream services as headers — services trust the gateway and never re-validate.
Rate Limiting
Common strategies: fixed window (100 req/min), sliding window, token bucket, leaky bucket. Rate limits can be applied per API key, per user, per IP, or per endpoint. When exceeded: return 429 with Retry-After and X-RateLimit-Remaining headers.
Request Aggregation
Instead of the client making 4 separate API calls to 4 services, the gateway makes them in parallel and returns a single aggregated response. Reduces client-side latency and network round trips — especially valuable for mobile clients.
Popular API Gateway Options
| Gateway | Type | Best For |
|---|---|---|
| AWS API Gateway | Managed (AWS) | Serverless/Lambda workloads on AWS |
| Kong | Open-source / Cloud | Complex setups, rich plugin ecosystem |
| Nginx + plugins | Self-hosted | Lightweight setups, existing Nginx users |
| Traefik | Open-source | Docker/Kubernetes-native auto-discovery |
| Azure API Management | Managed (Azure) | Azure workloads, enterprise API management |
| Cloudflare Workers | Edge compute | Edge routing + logic at CDN PoPs |
💡 You Might Not Need One Yet
For a monolith or early-stage product, an API gateway adds unnecessary complexity. Start without one. Add it when you have multiple backend services that share auth/rate limiting concerns, or when you need a developer portal for external API consumers.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — API Gateway
An API Gateway is a server that acts as the single entry point for all client API requests. Instead of clients calling individual microservices directly, they call the gateway, which routes requests to the appropriate backend service. The gateway handles cross-cutting concerns like authentication, rate limiting, logging, SSL termination, and request/response transformation — so individual services do not need to implement these themselves.
A reverse proxy (like Nginx) forwards requests to backend servers — primarily for load balancing, SSL termination, and caching. An API gateway does all of that plus higher-level API management: authentication/authorisation, rate limiting, request transformation, API versioning, developer portals, and analytics. Think of it as a smart reverse proxy with API-specific intelligence. In practice, many API gateways use Nginx or Envoy under the hood.
The BFF pattern creates a separate API gateway (or API layer) tailored for each type of client — one for the mobile app, one for the web app, one for third-party integrations. Each BFF aggregates data from multiple microservices and shapes the response for its specific client's needs. This avoids a one-size-fits-all API that over-fetches for mobile or under-fetches for web. Netflix pioneered this approach.
Yes — if you only run one gateway instance, it becomes a critical single point of failure. In production, API gateways are deployed in a highly available configuration: multiple instances behind a load balancer, auto-scaling groups, and health checks. Managed services like AWS API Gateway, Azure API Management, and Kong Cloud handle HA automatically. Self-hosted gateways require you to manage redundancy.
AWS API Gateway is a managed service — zero infrastructure to manage, pay per request, deep AWS integration (Lambda, IAM, Cognito). Kong is an open-source API gateway (Lua-based, runs on Nginx/OpenResty) — highly extensible via plugins, can be self-hosted or cloud-managed. Nginx is a web server/reverse proxy — lower-level, requires manual configuration for API management features like rate limiting and auth. AWS API Gateway is the fastest path for AWS workloads; Kong for complex multi-cloud setups.
Rate limiting restricts how many requests a client can make in a time window (e.g. 1000 requests/minute per API key). It protects backend services from abuse, prevents one client from monopolising resources, and provides a basis for tiered pricing (free vs paid tiers). The API gateway enforces rate limits before requests reach backend services. When exceeded, the gateway returns 429 Too Many Requests with a Retry-After header.