API Gateways
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 6 of 15
← Previous: Reverse Proxies → Next: DNS
Layer 1 — The building blocks · Post 6 of 88
An API gateway is a reverse proxy with extra jobs: auth, rate limits, request shaping, and a single front door for many backend services.
What you'll learn
What you put in a gateway versus what you leave in each service
The usual features: routing, auth, rate limits, aggregation
When a gateway helps — and when it becomes a bottleneck and a bureaucracy
The idea in one minute
You have many internal services: users, orders, catalog, billing. You do not want mobile apps and partner scripts to know all of them, speak five auth schemes, and retry in five different ways.
An API gateway is one public door: apps and partners hit the gateway; it authenticates, rate-limits, and routes to Users, Orders, Catalog, and Billing.
It is still a reverse proxy. The difference is product policy: who is allowed in, how often, and which backend they get.
Why it matters
Microservices without a front door leak internals. Every client becomes a distributed systems expert. Every service reimplements API keys, CORS, and throttling.
A gateway gives you:
One hostname (api.example.com) while the fleet behind it changes.
Cross-cutting rules in one place instead of twelve half-correct copies.
A place to version the public API (/v1, /v2) while backends move at their own speed.
It is not magic. Logic in the gateway is logic you still have to test, deploy, and on-call.
How it works
Think of a pipeline every request walks through:
TLS and HTTP — same as a reverse proxy.
Identify the client — API key, JWT, mTLS, OAuth token.
Authorize — is this client allowed to hit this route?
Rate limit — tokens, requests per second, burst (full post in Layer 3).
Route — path, header, or tenant → backend pool.
Maybe transform — rewrite paths, strip headers, pack JSON.
Maybe aggregate — one mobile call fans out to three services and merges the result (a BFF style gateway).
Backends stay private on an internal network. Only the gateway is exposed.
Gateway vs load balancer vs reverse proxy
Reverse proxy: Speak HTTP for your servers (TLS, routing, buffering)
Load balancer: Spread traffic across healthy copies
API gateway: Public API policy on top of that
In a small shop, one nginx or one cloud API Gateway product is all three. In a large shop, an edge LB feeds a fleet of gateway workers, which then call services (often through yet another internal LB). Draw as many boxes as you have real hop budgets — not as many as the textbook.
A simple example
A food-delivery app needs:
GET /restaurants → catalog service
POST /orders → orders service, but only with a valid user token
GET /orders/{id} → orders, same token, and the user must own the order (that last check still belongs in the orders service, not only in the gateway)
The gateway verifies the JWT, applies 100 requests/minute per user, and routes. If catalog is down, restaurants fail; orders can still be placed if you designed it that way. The gateway can return a fast 503 for /restaurants without waiting 30 seconds.
A partner integration uses an API key instead of a user JWT. Same gateway, different policy on /v1/partner/*.
Common mistakes
Putting business rules only in the gateway. Users can only see their own orders must be enforced in the service. The gateway can be bypassed by anyone on the internal network, including a buggy job.
One giant aggregation layer. A gateway that builds the entire home screen from 15 backends becomes a latency trap and a deploy bottleneck. Prefer a dedicated BFF or the app doing parallel calls with a budget.
Treating the gateway as optional in diagrams but mandatory in production. If every client hits services directly, you have N public surfaces to secure.
Forgetting the gateway is in the p99 budget. Auth cache misses, huge JWT parsing, and logging every payload will show up as the API is slow.
How this shows up in real systems
Kong, Ambassador, Tyk, AWS API Gateway, Apigee, Azure APIM: products in this slot.
GraphQL gateways / BFF servers: same idea, different payload shape.
Service mesh (Layer 5): sidecar proxies for service-to-service policy. The API gateway is usually the north-south (internet → you) door; the mesh is east-west (you → you). Many companies have both.
Interview move: put a gateway at the edge of microservices, name 2–3 policies (auth, rate limit, routing), and say what you will not put there.
Recap
An API gateway is a policy-aware reverse proxy for your public (or partner) APIs.
Use it for identity, throttling, routing, and hiding internals.
Keep authorization that protects data in the services that own the data.
Traffic has to find that gateway somehow. That starts with a name: DNS.
Layer 1 · Post 6 of 15
← Previous: Reverse Proxies → Next: DNS
Comments