Forward proxy vs reverse proxy vs API gateway vs load balancer
Published
All four are a machine in the middle that receives a request and passes it on. What makes them different is who they work for.
A forward proxy works for the clients. Think of the office receptionist who places every outside call for the staff: the person on the other end only ever sees the company's main number. A reverse proxy works for the servers. Think of the restaurant's front desk: you talk to one host, and you never learn which of the twelve cooks made your food. A load balancer and an API gateway are both reverse proxies with a particular job.
Your company's laptops reach the internet through Zscaler, and your app's users reach your servers through NGINX. Both are 'proxies'. Which one could block an employee from opening a gaming site, and which one could hide that you have forty backend servers?
- public address
- 1
- servers behind it
- 40
- servers the client knows
- 0
- box can do all of it
- 1
Forward proxy: on the client's side#
The clients are configured to send their traffic through it (or the network forces them to). It makes requests on their behalf. Typical jobs:
- Policy and filtering: a company blocks gaming sites, a school blocks social media. Zscaler, Squid and corporate web gateways do this.
- Caching shared downloads for many clients.
- Anonymity: the destination sees the proxy's IP, not the user's. VPNs and Tor are related ideas.
- Egress control in your own infrastructure: servers that must call outside APIs go through one proxy with a fixed IP, so a partner bank can allowlist that single address.
The server usually has no idea a forward proxy is involved, or which client is behind it.
Reverse proxy: on the server's side#
Clients think they are talking to the server. They are actually talking to the reverse proxy, which picks a backend and forwards the request. Typical jobs:
- TLS termination: certificates and encryption handled in one place.
- Hiding and protecting the backends: only the proxy is exposed to the internet.
- Caching and compression of responses.
- Routing:
/apito one service,/staticto another. - Buffering slow clients: the proxy absorbs a slow mobile upload so the app server is not tied up.
NGINX, HAProxy, Envoy, Caddy and Traefik are the common ones. A CDN like Cloudflare is a reverse proxy too, run on hundreds of edge locations.
Load balancer: a reverse proxy that spreads load#
Its defining job is choosing which of many identical servers gets each request or connection: round robin, least connections, consistent hashing. It also runs health checks and stops sending traffic to servers that fail them. Load balancers come in two flavours, layer 4 (sees connections) and layer 7 (sees HTTP requests), covered in L4 vs L7 load balancing and in depth in load balancing.
API gateway: a reverse proxy that understands your API#
An API gateway sits at the front door of a set of APIs and handles the concerns every API needs, so each service does not reimplement them:
- Authentication: validate the JWT or API key, reject anonymous calls early.
- Rate limiting and quotas per key or per user.
- Routing to many different services by path, version or header (
/v2/ordersto the new orders service). - Request and response transformation, protocol translation (REST outside, gRPC inside).
- Analytics, logging and developer keys for public APIs.
Kong, AWS API Gateway, Apigee, Tyk and Envoy based gateways are the usual names.
Gateways tempt teams to add "just one small check" until business logic is spread across a proxy config nobody can test. Keep the gateway to cross cutting, generic concerns. "Is this token valid?" belongs there. "May Ravi edit invoice 4471?" belongs in the service (see authentication vs authorization).
The honest truth: one box, many hats#
These are roles, not products. A single NGINX can terminate TLS, cache, route by path, balance across servers and enforce rate limits, so it is a reverse proxy, a load balancer and a small API gateway at once. On AWS a common stack is CloudFront (CDN), then API Gateway or an Application Load Balancer, then services. In Kubernetes, an ingress controller plays the reverse proxy and load balancer role at the edge, and a service mesh puts a small reverse proxy (an Envoy sidecar) next to every service for traffic between services.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Forward proxy | Central control over what clients can reach, one egress IP, shared caching. | Another hop for every outbound request, and a single point of failure for egress. | Corporate networks, schools, server egress to partners that allowlist IPs. |
| Reverse proxy | TLS, caching, compression and routing in one place, backends hidden. | An extra hop, and it must itself be redundant. | In front of almost every web application. |
| Load balancer | Horizontal scaling, health checks, zero downtime deploys. | Needs its own redundancy. Sticky sessions undermine it. | As soon as there is more than one server. |
| API gateway | Auth, rate limits, keys and routing done once for many services. | Latency, cost per request on managed gateways, and a magnet for misplaced logic. | Many services behind one public API, or a public developer API. |
- NGINXReverse proxy, load balancer, light gateway
- EnvoyProxy behind Istio and many gateways
- KongAPI gateway built on NGINX
- API GatewayAWS managed API gateway
- AWS ELBAWS load balancers: ALB (L7), NLB (L4)
- CloudflareCDN, a reverse proxy at the edge
In the interview#
Checkpoint#
1. What is the core difference between a forward and a reverse proxy?
2. Which job belongs in an API gateway?
3. Is a CDN a forward or a reverse proxy?
- Forward proxy works for clients. Reverse proxy works for servers.
- Load balancer: reverse proxy that spreads load and health checks.
- API gateway: reverse proxy for API concerns: auth, rate limits, routing, keys.
- They are roles, not products. One NGINX or Envoy often plays several.
- Keep business rules out of the gateway.
All four sit in the middle of a request; the difference is who they work for. A forward proxy acts on behalf of clients: corporate filtering, caching, anonymity, or a fixed egress IP that partners can allowlist, and servers see the proxy rather than the client. A reverse proxy acts on behalf of servers: clients see one address, and it handles TLS termination, caching, compression and routing while hiding the backends. A load balancer is a reverse proxy whose main job is spreading traffic over identical instances with health checks. An API gateway is a reverse proxy that understands APIs, doing authentication, rate limiting, routing and keys once for many services. They are roles rather than products, so one NGINX or Envoy often plays several, and in Kubernetes an ingress handles the edge while a mesh puts a proxy beside each service. I keep the gateway stateless and redundant, and keep business rules out of it.