In system design and distributed architectures, these three components are often confused, but
they serve distinct roles — and in practice, a single production system usually uses all
three together, layered on top of each other.
1️⃣ API Gateway
- Acts as a single entry point for client-facing APIs — crucial in a microservices architecture where dozens of services would otherwise each need their own public endpoint.
- Handles authentication, authorization, and rate limiting to secure and monitor API traffic.
- Implements request routing to the correct microservice, and can aggregate/compose multiple backend responses into a single response (API composition / backend-for-frontend).
- Other common responsibilities: request/response transformation, API versioning, request validation, quota management, analytics/logging.
- Examples: AWS API Gateway, Kong, Apigee, Zuul.
2️⃣ Load Balancer
- Distributes incoming traffic evenly across multiple backend servers/instances for high availability and horizontal scalability.
- Prevents server overload and provides fault tolerance by detecting failed instances (health checks) and routing away from them.
- Operates at either:
- Layer 4 (Transport — TCP/UDP): routes based on IP/port, very fast, protocol-agnostic, no visibility into HTTP content.
-
Layer 7 (Application — HTTP/HTTPS): can route based on URL path, headers, cookies; enables
smarter routing (e.g.,
/api/v1/*→ service A) but adds a bit more overhead.
- Examples: AWS ELB/ALB/NLB, NGINX, HAProxy.
3️⃣ Reverse Proxy
- Sits in front of one or more backend servers and forwards client requests to them — clients never talk to the backend servers directly.
- Adds security by hiding backend server details/IP addresses (backend is not directly internet-addressable), and can filter malicious traffic.
- Commonly performs SSL/TLS termination (decrypts HTTPS at the proxy so backend servers don't bear that CPU cost) and caching of static/responses to improve performance.
- Examples: Nginx, Apache HTTP Server (mod_proxy), Envoy, Traefik.
🎯 Key Distinction — Purpose, Not Just Technology
The confusing part: the same software (e.g., NGINX) can act as all three, depending on
configuration. The distinction is about role/intent, not the specific product:
| Aspect | API Gateway | Load Balancer | Reverse Proxy |
|---|---|---|---|
| Primary purpose | API management (auth, rate limit, routing, composition) | Distribute traffic across many servers | Forward/hide backend, terminate SSL, cache |
| Layer | Usually L7, API-aware | L4 or L7 | Usually L7 |
| Client-facing? | Yes, single entry point for APIs | Sometimes (public-facing) or internal | Yes, typically |
| Knows about business logic/APIs? | Yes (routes per-endpoint, auth per-API) | No, just traffic distribution | Not necessarily |
| Adds auth/rate limiting? | Yes, core feature | No (not its job) | Not typically (can via plugins) |
| Example | AWS API Gateway, Kong | AWS ELB, NGINX (as LB) | NGINX (as proxy), Envoy |
Mental model:
- Reverse Proxy = "I sit in front of your server(s) and hide them; I may also cache/terminate TLS."
- Load Balancer = "I sit in front of many servers and decide which one gets each request."
- API Gateway = "I sit in front of your APIs, and I understand and manage API-level concerns (auth, quotas, routing per endpoint, aggregation)."
A Load Balancer and Reverse Proxy are often the same deployed component performing overlapping
duties (many reverse proxies also load balance). An API Gateway is typically a more specialized,
higher-level layer sitting in front of a load balancer, not a replacement for one.
🏗️ How They Typically Fit Together in a Real Architecture
Client
→ CDN (optional, static/cacheable content)
→ API Gateway (auth, rate limiting, routing, composition)
→ Load Balancer (distributes across service instances)
→ Reverse Proxy (per-service, TLS termination/caching) [often merged into the LB layer]
→ Backend service instances
In many real deployments, the reverse proxy and load balancer are literally the same NGINX/Envoy
instance — "reverse proxy" describes what it's doing (hiding/forwarding to backends), while
"load balancer" describes how it decides where to forward (distribution algorithm).
🎯 Q&A
Can one tool act as all three (API Gateway, LB, and Reverse Proxy)?
Yes — NGINX and Envoy are commonly configured to do all three simultaneously: terminate TLS
(reverse proxy), distribute traffic across upstream instances (load balancer), and with plugins/
extensions (or paired with Kong), handle auth/rate-limiting/routing (API gateway). The distinction
is about the role being performed, not a strict 1:1 mapping to a specific product.
Why would you need both an API Gateway and a Load Balancer?
The API Gateway handles cross-cutting API concerns (auth, quotas, per-endpoint routing,
composition) once, at the edge — it typically then forwards the request to a load balancer, which
handles the mechanics of picking which specific healthy instance of that service should serve
the request. They operate at different levels of abstraction: API Gateway = "which service, with
what policy," Load Balancer = "which instance of that service, right now." This also answers where
rate limiting belongs — at the API Gateway, since it's an API-level policy tied to caller identity,
not something a Load Balancer (which is only aware of traffic distribution and health) is designed
to handle.
L4 vs L7 load balancing — when would you choose each?
L4 (TCP/UDP) is faster and simpler — good when you just need raw connection distribution and don't
care about HTTP semantics (e.g., a database proxy, or extremely high-throughput traffic where every
microsecond counts). L7 (HTTP-aware) is needed when routing decisions depend on the request content
— path-based routing (/api/* vs /static/*), header/cookie-based session affinity, or
A/B testing/canary routing by request attributes.
How does a reverse proxy improve security?
It hides backend server IPs/topology from the public internet (backends aren't directly
addressable), centralizes where security policies (WAF rules, IP allowlisting, TLS
termination/certificate management) are enforced, and can absorb/filter malicious traffic (e.g.,
basic DDoS mitigation, malformed request rejection) before it ever reaches application servers.
What's the difference between a forward proxy and a reverse proxy?
A forward proxy sits in front of clients and makes requests on their behalf to the internet
(e.g., corporate proxy hiding internal users from external sites — the server doesn't know who
the real client is). A reverse proxy sits in front of servers and handles requests on their
behalf from clients (the client doesn't know which backend server actually served the request).
Does adding a Reverse Proxy/Load Balancer/API Gateway add latency?
Technically each hop adds some latency (extra network hop + processing), but it's usually
negligible (sub-millisecond to a few ms) compared to the benefits: security, TLS offload, caching,
smarter routing, and horizontal scalability — which reduce overall latency far more than the
hop itself costs, especially under load.
Summary
An API Gateway manages API-level concerns like auth, rate limiting, and routing across
microservices. A Load Balancer distributes traffic across multiple instances of a service for
availability and scale. A Reverse Proxy sits in front of backend servers to hide them, terminate
TLS, and cache responses. In practice they're often layered together, and the same software (e.g.,
NGINX) can perform all three roles depending on configuration.
Top comments (1)
tr.ee/dev-to