API Gateways
Updated June 3, 2026When Netflix moved from a monolith to microservices, they had a problem. Their mobile clients needed to talk to dozens of different backend services — a user service, a content catalog, a recommendations engine, a billing service. Asking the iOS app to make 15 separate API calls and stitch the responses together was a nightmare. The solution was an API gateway.
What an API Gateway Does
An API gateway is a server that acts as the single entry point for all client requests. Instead of clients communicating directly with backend services, they send requests to the gateway, which figures out where to forward them.
Think of it as the concierge desk at a large hotel. You don't wander through the building looking for housekeeping or the restaurant directly. You call the front desk and they route you to the right person.
At the simplest level, an API gateway does request routing: it receives requests on a single public address and forwards them to the appropriate internal service based on the URL path, headers, or other request attributes.
But in practice, gateways do a lot more.
Single entry point — all client requests hit the gateway, which routes to backend services
Core Features of an API Gateway
Authentication and Authorization
The gateway is the perfect place to verify that incoming requests are legitimate before they ever reach your backend services. Instead of implementing auth logic in every microservice, you centralize it at the gateway.
Common patterns:
- Validate a JWT token in the
Authorizationheader - Check an API key against a database
- Delegate to an OAuth provider (verify the token with Auth0 or Cognito)
If the token is invalid, the gateway returns 401 Unauthorized immediately — your backend services never see the request.
When an API gateway handles authentication, what happens to a request with an invalid JWT token?
Rate Limiting
The gateway enforces limits on how many requests a client can make in a given time window. Without this, a single misbehaving client (or a DDoS attempt) can saturate your backends.
A gateway can enforce limits at multiple granularities: per-IP (e.g. 100 requests/minute per address), per-user (e.g. 1000 requests/hour per authenticated user), and per-endpoint (a tighter limit on /v1/videos/render than on /v1/health).
When a client exceeds their limit, the gateway returns 429 Too Many Requests with a Retry-After header.
When a client exceeds the rate limit enforced by an API gateway, the gateway returns HTTP 429.
SSL Termination
HTTPS traffic is encrypted. Before your backend services can read the request, someone has to decrypt it. Doing this on every service is wasteful — each service would need a TLS certificate, and the CPU cost of encryption/decryption would multiply across the fleet.
Instead, the gateway terminates SSL: it receives encrypted HTTPS traffic from clients, decrypts it, and forwards plain HTTP internally. Your internal network traffic stays within a controlled environment (typically a VPC), so the lack of encryption internally is acceptable.
This also means TLS certificate management is centralized — you renew one certificate at the gateway rather than certificates on 50 services.
Why does an API gateway terminate SSL instead of passing encrypted traffic directly to backend services?
Request Logging and Observability
Every request that enters your system passes through the gateway, making it the ideal place to capture observability data:
- Request/response logs with timestamps, latency, status codes
- Distributed trace IDs (injected into request headers and propagated through the call chain)
- Metrics aggregation for dashboards and alerts
Without a gateway, you'd have to instrument every service independently to get a complete picture of system behavior.
Routing and Load Balancing
Gateways can route requests to different backend services based on the request path (/api/users/* to the User Service, /api/payments/* to the Payment Service), the host header (api.myapp.com to production, staging-api.myapp.com to staging), arbitrary headers (e.g. X-Feature-Flag: new-checkout for A/B testing), or weighted routing that splits a percentage of traffic to a canary deployment.
Many gateways also do basic load balancing across multiple instances of the same service, though dedicated load balancers (like AWS ALB) often sit in front of the gateway itself.
Request/Response Transformation
Gateways can modify requests in flight: they can add headers before forwarding (injecting the user ID decoded from the JWT), strip sensitive headers before they reach the backend, transform request formats (JSON to XML for a legacy internal service), and aggregate responses from multiple backend calls into a single response — a pattern known as the Backend for Frontend (BFF).
Gateway cross-cutting concerns — auth, rate limiting, SSL termination, logging, routing in one layer
API Gateway vs Reverse Proxy
This distinction comes up in interviews and it's worth being precise.
A reverse proxy is a server that forwards client requests to one or more backends. It typically handles SSL termination and load balancing. Nginx and HAProxy in HTTP mode are reverse proxies.
An API gateway is a reverse proxy with higher-level features: it understands your API specifically, handles authentication, enforces rate limits, and provides observability designed for API traffic.
All API gateways are reverse proxies. Not all reverse proxies are API gateways.
The line is blurry in practice — Nginx with a bunch of plugins can function as a basic API gateway. The distinction is more about purpose and feature richness than a binary technical difference.
All reverse proxies qualify as API gateways.
Real Products
AWS API Gateway
The managed AWS option. Deeply integrated with Lambda (you can invoke Lambda functions directly from route configurations), IAM, and Cognito. Supports REST and WebSocket APIs. Auto-scales to zero — you pay per request, not per hour.
The main downside is vendor lock-in and sometimes surprising latency overhead for high-frequency, low-latency API calls. It also has a steeper learning curve than its managed nature implies.
Kong
Open-source and enterprise API gateway built on top of Nginx/OpenResty. Kong's plugin architecture is its killer feature — you install plugins for rate limiting, auth, logging, and transforms, and they compose cleanly. It can run on-prem, on Kubernetes, or as a managed cloud service (Kong Konnect).
Kong is the go-to for teams that want gateway power without full AWS lock-in.
Apigee (Google Cloud)
Apigee is enterprise-grade API management — heavy features around API monetization, developer portals, and analytics. It's used by large enterprises that need to expose APIs to third-party developers at scale (think telcos, financial institutions). More complex than Kong or AWS API Gateway, and priced accordingly.
Nginx
With the right configuration and plugins (like the Nginx Plus rate limiting module), Nginx can serve as a capable API gateway. Many smaller teams use Nginx for gateway-like functionality without adopting a dedicated API gateway product. It's less feature-rich but has extremely predictable performance characteristics.
Which API gateway product is known for a plugin architecture built on top of Nginx/OpenResty?
Summary
An API gateway is the front door to your microservices architecture. It centralizes cross-cutting concerns (auth, rate limiting, SSL termination, logging) so your individual backend services can focus on their actual domain logic. Auth at the gateway means one place to update security policies. Rate limiting at the gateway protects all services with a single config. SSL termination at the gateway simplifies certificate management across the fleet. Routing at the gateway decouples public URLs from internal service topology, so you can restructure your backends without touching client code.
If you're designing a system with more than a handful of microservices, an API gateway isn't optional — it's the thing that keeps client-side complexity manageable.
Saved on this device only
Sign in to sync progress across devices