Reverse Proxy and API Gateway
A Reverse Proxy / API Gateway is a 'receptionist' standing in front of the backend servers: it takes all requests, checks them and passes them to the right service.
4.1 Why is it used?
- A client should not need to know the separate addresses of 50 microservices. It needs one entry point (api.example.com).
- Common work like authentication, rate limiting, logging and SSL is done once at the gateway instead of being written in every service.
- The backend servers' IPs stay hidden, which improves security.
- API versioning, request/response transformation, caching and compression all happen in one place.
- For a mobile app, several service calls can be combined into one response (aggregation / Backend-for-Frontend).
4.2 How it works
- 1.Mobile App -> api.foodapp.com (Authorization: Bearer JWT)
- 2.API Gateway (Kong / AWS API GW) step 1: verify JWT, and if the token is bad return 401 Unauthorized right there
- 3.Step 2: Rate limit (1 user = 100 req/min), and if the limit is crossed return 429 Too Many Requests
- 4.Step 3: Route by path + version / canary: GET /restaurants -> restaurant-service, POST /orders -> order-service v1 (95%) / v2 (5% canary), GET /track -> delivery-service
- 5.Step 4: Log + metrics (latency, status code) -> Prometheus + Grafana monitoring
The client sees only the gateway; backend IPs stay hidden and the services live in a private network
- Forward proxy vs Reverse proxy: a forward proxy is on the client's side (office proxy), a reverse proxy is on the server's side (Nginx in front, app behind).
- What a reverse proxy does: SSL termination, caching, compression (gzip/brotli), load balancing, serving static files.
- API Gateway = reverse proxy + API-specific features: auth (JWT/OAuth/API key), rate limit, quotas, API keys, analytics, developer portal.
- Routing: /users/* -> user-service, /orders/* -> order-service; also on the basis of a header or version (v1/v2).
- Request transformation: add/remove headers, rename JSON fields, convert REST to gRPC/Lambda.
- Plugins / filters: Kong plugins, Envoy filters. Features like auth, CORS, logging and circuit breaking can be switched on/off.
- BFF (Backend For Frontend): a separate gateway for mobile and web that shapes data to their needs.
- The gateway itself must not become a bottleneck: keep it stateless, scale it horizontally, run multiple instances behind an LB.
- The difference between the three: a Load Balancer spreads traffic, a Reverse Proxy hides the servers (SSL, cache, compression), and an API Gateway adds API features like auth, rate limit and versioning.
4.3 Which tools can be used
| Tool | Type | How it is used |
|---|---|---|
| Nginx | Reverse proxy / web server | Forwards to the backend with proxy_pass, plus SSL, caching, rate limit. Enough for a simple gateway. |
| Kong | Open-source API Gateway (Nginx/OpenResty based) | JWT auth, rate limit, key-auth and logging through plugins; also a Kubernetes Ingress controller. |
| AWS API Gateway | Managed API Gateway | Serverless; sits in front of Lambda/HTTP backends, with throttling, API keys, usage plans, Cognito auth. |
| Envoy | Cloud-native L7 proxy | The base of the Istio service mesh and Envoy Gateway; gRPC, retries, circuit breaking, observability. |
| Apigee (Google) | Enterprise API management | API products, monetization, analytics, developer portal. For partner APIs in banks/telecom. |
| Azure API Management | Managed API Gateway (Azure) | Auth, rate limit and transforms through policies; comes with a developer portal. |
4.4 Comparison: Nginx vs Kong vs AWS API Gateway vs Envoy
| Point | Nginx | Kong | AWS API Gateway | Envoy |
|---|---|---|---|---|
| Type | Reverse proxy / web server | API Gateway (built on Nginx) | Fully managed gateway | L7 proxy / service mesh data plane |
| Performance | Very fast, low memory | Fast, a little overhead from plugins | A little extra latency, auto scales | Very fast, C++ |
| API features (auth, keys, quotas) | Basic, manual config | Rich plugin ecosystem | Built-in API keys, usage plans | Through filters, needs a control plane |
| Config | Static config file, reload | Admin API / declarative YAML | Console / IaC (CloudFormation, Terraform) | Dynamic xDS API (via Istio) |
| Management | Self-managed | Self-managed or Kong Konnect (SaaS) | Zero server management | Self-managed or through the mesh |
| Cost | Free | Free OSS, Enterprise paid | Per million requests | Free |
| Best for | Simple reverse proxy, static content | Self-hosted full API gateway | Serverless / AWS apps | Microservices, Kubernetes, gRPC |
4.5 When to choose which
- Nginx: you need SSL + routing + caching in front of a simple website/app.
- Kong: you need a self-hosted or multi-cloud API gateway with plugins (auth, rate limit).
- AWS API Gateway: a Lambda/serverless backend, and you do not want to manage servers.
- Envoy / Istio: traffic control and observability between Kubernetes microservices (east-west).
- Apigee / Azure APIM: you sell or give APIs to external partners and need a developer portal and analytics.
4.6 Real-world example
Scenario: a food delivery app like Swiggy/Zomato
- The mobile app calls only one domain, api.foodapp.com.
- The request reaches the API Gateway; the gateway verifies the JWT token. If it is invalid, it returns 401 right there.
- The gateway checks the rate limit: one user gets no more than 100 req/min.
- GET /restaurants is routed to restaurant-service, POST /orders to order-service, GET /track to delivery-service.
- For the home screen the BFF fetches banners, restaurants and offers from 3 services in one call and combines them.
- Each request's log and latency metric go from the gateway to monitoring (Prometheus/Grafana).
- A new order-service v2 arrives; the gateway sends 5% of traffic to v2 (canary), and if all is well, 100%.
4.7 Interview tips
- The difference between a Load Balancer, a Reverse Proxy and an API Gateway is definitely asked: the LB spreads traffic, the reverse proxy hides servers, the gateway gives API features.
- Mistake: putting business logic in the gateway. The gateway should do only cross-cutting work (auth, routing, limits).
- Mistake: a single gateway instance. The whole system depends on it, so HA + auto-scaling are essential.
- Mistake: writing separate auth in every service when it could have been centralized at the gateway.
- Trade-off: the gateway is an extra network hop and a possible bottleneck, so keep it stateless and scale it horizontally.