Reverse Proxy vs API Gateway vs Load Balancer
What each should actually do, and where teams usually blur the lines
Goal: help you assign the right responsibilities to the right layer so your edge stack stays understandable instead of slowly turning into a pile of routing rules, auth hacks, and impossible-to-debug failures.
TL;DR
- A reverse proxy should sit in front of upstream servers and handle HTTP-aware edge concerns like TLS termination, header normalization, compression, caching, and host/path routing.
- A load balancer should distribute traffic across multiple healthy backends and make failover boring through health checks, connection draining, and traffic-spreading policies.
- An API gateway should be the policy and product layer for APIs: auth, rate limits, quotas, CORS, API keys, request validation, analytics, version exposure, and sometimes developer onboarding.
- These are roles, not mutually exclusive products. One product can play more than one role.
- The most common mistake is treating the gateway as your business-logic layer. The second most common mistake is treating a load balancer like it should own API policy.
1) The simplest mental model
Think in responsibilities, not brands:
Client
-> Reverse proxy or API gateway at the edge
-> Load balancer across app instances
-> Application services
In real systems, one box can cover multiple layers:
- NGINX can be a reverse proxy and a load balancer.
- Envoy can be a reverse proxy, load balancer, and part of a gateway stack.
- Kong, Apigee, and managed API gateway products are gateways that also proxy requests.
- A cloud Application Load Balancer can do routing that feels reverse-proxy-like.
That overlap is normal. The key question is still: what job should this layer own?
2) What is the difference between a reverse proxy, API gateway, and load balancer?
Reverse proxy
A reverse proxy accepts requests from clients and forwards them to upstream servers while hiding the upstream topology from the client.
Good at:
- TLS termination
- host/path routing
- header rewriting and forwarding
- compression
- response buffering
- static asset delivery
- caching
- origin shielding
Load balancer
A load balancer chooses which backend instance should handle a request or connection.
Good at:
- distributing traffic across instances
- health checks
- failover
- session affinity when needed
- connection draining
- cross-zone or cross-node traffic spreading
API gateway
An API gateway is an API-focused edge layer that sits in front of backend services and standardizes how clients access them.
Good at:
- auth and authz at the edge
- API keys, quotas, and rate limits
- request/response validation
- API version exposure
- CORS handling
- API analytics and usage visibility
- sometimes documentation portals or product packaging
3) What each should actually do
3.1 Reverse proxy: shape and protect traffic at the HTTP edge
A reverse proxy should own the things that make raw HTTP traffic safe, consistent, and efficient before it reaches your app.
It should usually do things like:
- terminate TLS
- normalize and forward
X-Forwarded-*or equivalent headers - route by hostname, path, or protocol
- compress responses
- cache safe content where appropriate
- buffer slow clients away from upstreams
- enforce sensible request body and timeout limits
- hide internal topology from clients
It should usually not be where you put:
- API product policy
- per-customer quotas
- complex auth decisions
- business workflows
- deep request transformation that only one service understands
If your app is "one web app plus an app server," a reverse proxy might be all you need.
3.2 Load balancer: keep traffic spread across healthy backends
A load balancer should answer one operational question well:
Which healthy backend should get this request right now?
It should usually do things like:
- route traffic only to healthy targets
- spread traffic across instances or zones
- stop sending traffic to broken instances
- drain connections during deploys or autoscaling events
- optionally preserve stickiness when the app truly needs it
- surface health and traffic metrics
It should usually not be where you put:
- OAuth or JWT policy
- public API lifecycle management
- custom response aggregation
- per-team routing logic mixed with app semantics
A load balancer is mostly about availability and distribution, not API design.
3.3 API gateway: own API policy, not core application behavior
An API gateway should be the place where clients meet consistent API rules.
It should usually do things like:
- validate auth tokens or API keys
- enforce scopes, plans, quotas, and rate limits
- expose stable public routes to unstable internal services
- handle CORS consistently
- apply request validation and basic schema guardrails
- centralize API observability, auditability, and usage analytics
- support versioning and controlled rollouts at the edge
It can sometimes do:
- lightweight request or header transformation
- response shaping for compatibility transitions
- simple aggregation for edge convenience
It should usually not do:
- order processing logic
- payment logic
- workflow orchestration
- deep business rules that belong in services
- become the only place auth is enforced
If your gateway contains most of your product logic, you probably built a distributed monolith with better marketing.
4) Side-by-side: responsibilities vs anti-patterns
| Layer | Should do | Should not become | |---|---|---| | Reverse proxy | TLS termination, routing, headers, compression, buffering, caching | Your API product layer | | Load balancer | Health checks, distribution, failover, draining, affinity | Your auth or transformation engine | | API gateway | Auth, quotas, rate limits, CORS, validation, API analytics | Your business-logic monolith |
5) The layers people confuse most
"Is an API gateway just a reverse proxy?"
Not quite.
An API gateway usually includes reverse-proxy behavior, but the extra value is API-specific policy and management:
- client identity
- auth rules
- quotas and plans
- standardized API exposure
- analytics
If all you are doing is path routing and header forwarding, you probably have a reverse proxy, not much of a gateway.
"Is a load balancer just a reverse proxy?"
Sometimes a reverse proxy product can also load balance, but the roles are different.
- A reverse proxy focuses on how traffic is handled at the HTTP edge.
- A load balancer focuses on where traffic is sent among multiple backends.
One tool can do both. The responsibilities are still distinct.
"Can I skip the gateway if I already have a load balancer?"
Yes, often.
If you have:
- one app
- one client type
- no public API program
- no complex auth or quota policy
then a reverse proxy plus load balancer is often enough.
Add an API gateway when API policy becomes a real product or platform concern.
6) A practical way to choose
Use a reverse proxy when
- you need TLS termination
- you need host/path routing
- you want compression, buffering, or caching
- you want to hide internal services from clients
Use a load balancer when
- you have more than one backend instance
- you need health-aware routing
- you need rolling deploys without dropping traffic
- you need zone or node distribution
Use an API gateway when
- your APIs are exposed to multiple clients or third parties
- you need auth, quotas, and rate limits enforced consistently
- you need a stable public contract over changing internal services
- you need API analytics, lifecycle control, or developer-facing API management
Use them together when
- you run a serious internet-facing platform
That stack often looks like:
Client
-> CDN / WAF
-> API gateway or reverse proxy
-> load balancer
-> service instances
In smaller systems, some of those roles collapse into one product. That is fine. The separation is conceptual first.
7) What small teams should do first
For most small teams:
- Start with a reverse proxy.
- Add a load balancer once you run multiple instances.
- Add an API gateway only when API policy, external consumers, or platform governance justify it.
This is a better default than installing a giant gateway platform on day one because "we might have microservices later."
8) Common production mistakes
Putting business logic in the API gateway
This makes changes slower, testing worse, and failures harder to reason about.
Treating the load balancer as the security boundary
A load balancer can help with exposure and topology, but it is not your full auth or authorization story.
Letting every service interpret forwarded headers differently
If your reverse proxy sets client IP, protocol, or host headers, standardize how downstream services trust and parse them.
Forgetting that edge auth is not enough
The gateway should reject obviously invalid requests early, but services still need defense in depth for sensitive actions.
Using session affinity to hide broken state design
Sticky sessions can be practical, but if they are required everywhere forever, you may be compensating for deeper application-state problems.
9) Real examples
Simple SaaS app
- Reverse proxy: TLS, compression, static asset caching
- Load balancer: spread traffic across app instances
- API gateway: not necessary yet
Public API platform
- Reverse proxy: maybe present inside the gateway layer
- Load balancer: distribute across gateway nodes or backend services
- API gateway: auth, quotas, API keys, analytics, versioned routes
Internal microservices platform
- Reverse proxy: ingress or edge routing
- Load balancer: service distribution and health-aware failover
- API gateway: optional for north-south traffic
For east-west traffic, a service mesh may matter more than a public-style API gateway.
10) FAQ
Do microservices always need an API gateway?
No. Many internal systems run perfectly well with ingress or reverse-proxy routing plus service-to-service auth and observability. A gateway becomes more valuable when you have public clients, partner APIs, or strong API governance requirements.
Can one product be all three?
Yes. Many products combine reverse proxying, load balancing, and gateway features. That does not mean you should mix all responsibilities indiscriminately.
Is Kubernetes Gateway API the same thing as an API gateway?
No. Gateway API in Kubernetes is a Kubernetes traffic-management API model. It can be used by implementations that provide ingress and edge routing, but it is not automatically the same thing as a full API management gateway with quotas, plans, developer portals, and API product controls.
Should authentication live only at the gateway?
No. The gateway should handle early rejection and consistent edge policy, but sensitive services should still enforce their own authorization rules.
If I already use a CDN, do I still need a reverse proxy?
Often yes. A CDN handles edge caching and delivery, but many systems still need an origin-side reverse proxy or ingress layer for routing, upstream handling, headers, buffering, and internal service topology.
11) Final recommendation
If you need one simple rule:
- Reverse proxy for HTTP edge handling
- Load balancer for traffic distribution and health
- API gateway for API policy and product control
That division of responsibilities is still the cleanest default in April 2026.
If you want the narrower gateway-only explainer, see What is an API Gateway?. For related background, see Nginx vs Apache, rate limiting strategies, and HTTP caching deep dive.