API gateway
A single entry point that fronts many backend services, handling auth, rate limiting, routing, and request shaping. It's a specialized reverse proxy for APIs. Clients talk to one API surface; the gateway fans out.
- Many services behind one client-facing API.
- Centralizing auth, quotas, and usage metering for external APIs.
- Single internal service with no shared policy needs.
- When a service mesh sidecar already provides the policy.
Definition
An API gateway sits between clients and services, providing a unified API with cross-cutting concerns: authentication, authorization, rate limiting, quota, request/response transformation, observability, and routing to backends.
Why it exists
Without a gateway, every service reimplements auth and limits, and clients juggle many URLs. A gateway centralizes policy and presents a clean, versioned API surface to clients.
How it works
Client calls the gateway with a token; the gateway validates auth, applies rate limits and quotas, transforms the request, routes to the right backend (possibly aggregating several), and returns. Can be a product (Kong, AWS API Gateway) or code (a thin service).
Scaling limits
The gateway is a hot path and single point of control; it must scale horizontally and stay stateless. Heavy request transformation or per-request aggregation creates fan-out load on backends.
Cost shape
Managed gateways charge per-request + features. Self-hosted costs compute plus ops. Blow-up: per-request Lambda authorizers or transforms adding latency to every call.
Alternatives
- Reverse proxy + app middleware — More flexible, but you build the policy layer yourself.
- Service mesh — East-west policy without a north-south chokepoint, but not a client API surface.
Failure modes
- Becoming a bottleneck or single point of failure.
- Per-request authorizer latency piling up.