Overview
An API gateway is a single entry point that sits in front of many backend services. Clients call one domain; the gateway authenticates the request, applies rate limits and quotas, routes it to the correct service, and can transform requests and responses or aggregate several calls.
It centralizes cross-cutting concerns that every service would otherwise re-implement, and it decouples clients from the internal service layout, so services can be split, merged, or moved without breaking clients. The risk is turning it into a bottleneck or a place where business logic accumulates.
Every passenger goes through one checkpoint that verifies identity and tickets, then the information desk directs them to the right gate. Gates (services) do not each run their own security.
When to use it
- Microservices exposed to external clients.
- Consistent authentication, rate limiting, and logging across services.
- Public APIs with API keys, quotas, and usage plans.
- Hiding internal service topology and protocols from clients.
Where it shows up in interviews
Recognize it when: many services, external clients, shared auth.
- Design Uber's API layer
- Design an e-commerce platform
Recognize it when: API keys, plans, quotas, analytics.
- Design a developer platform
- Design a rate-limited public API
Where it is used in real software
AWS API Gateway, Azure API Management, and Google Apigee provide auth, throttling, usage plans, and monitoring.
Kong (built on Nginx/OpenResty), Envoy Gateway, and Tyk are popular open-source options.
Netflix's edge gateway routes billions of requests a day and handles resilience and canary routing.
Key terms
- Routing
- Map /orders/* to the orders service, /users/* to the users service.
- Authentication offload
- Validate tokens at the gateway and pass user identity downstream.
- Rate limiting / quotas
- Limit requests per client, key, or plan.
- Request aggregation
- Combine several backend calls into one client response.
- BFF
- Backend for frontend: a gateway tailored to one client type.
How it works, step by step
- 1Terminate TLS
One certificate for api.example.com.
- 2Authenticate
Validate the API key or JWT; reject with 401 if invalid.
- 3Apply policies
Rate limits, quotas, request size limits, and IP rules.
- 4Route and transform
Pick the service by path, add identity headers, strip internal headers.
- 5Observe
Record latency, status, and consumer for metrics and billing.
STEP 1GET /orders/9001 arrives at api.example.com with a bearer token.
Gateway vs load balancer vs service mesh
Three layers often confused in interviews
| Component | Traffic | Main job |
|---|---|---|
| Load balancer | Any, north-south | Spread traffic across healthy instances |
| API gateway | External API (north-south) | Auth, quotas, routing, API management |
| Service mesh | Service-to-service (east-west) | mTLS, retries, observability between services |
NOWComponent: Load balancer | Traffic: Any, north-south | Main job: Spread traffic across healthy instances
A typical design uses all three: load balancer in front of gateway instances, gateway for external APIs, and a mesh for internal calls.
Implementation
_format_version: "3.0"services: - name: orders url: http://orders.internal:8080 routes: - name: orders-route paths: ["/v1/orders"] plugins: - name: jwt # validate bearer tokens - name: rate-limiting config: { minute: 600, policy: redis, redis_host: redis.internal } - name: request-size-limiting config: { allowed_payload_size: 1 } # MB - name: users url: http://users.internal:8080 routes: - name: users-route paths: ["/v1/users"]Complexity and performance
Depends on plugins (auth, rate limit lookups).
Every request passes through it.
Trade-offs
Shared policies in one place are powerful, but a gateway that holds business logic becomes a bottleneck every team depends on.
A single gateway is simpler; separate BFFs let web and mobile teams tailor aggregation without conflicts.
Variants and related techniques
Per-client gateways that aggregate and shape data for one UI.
Gateway for external edge policies, mesh for internal traffic.
Common mistakes
- Business logic in the gateway.
Fix: Keep it to cross-cutting concerns; business rules belong in services.
- Services trusting any X-User-Id header.
Fix: Only accept identity headers from the gateway (network policy or mTLS), or re-verify tokens.
- Single gateway instance.
Fix: Run it redundantly across zones behind a load balancer.
Interview questions
What would you put in an API gateway?
TLS termination, authentication, rate limiting and quotas, routing, request validation, CORS, logging and metrics, and simple transformations. Not business logic.
How do you avoid the gateway becoming a bottleneck?
Scale it horizontally and statelessly, keep plugins fast (cache token validation, use local rate-limit counters with periodic sync), and keep logic minimal.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Draw a gateway in front of 5 services | Easy | Routing and auth. |
| Design API keys and usage plans for a public API | Medium | Quotas and billing. |