Load Balancer vs Reverse Proxy vs API Gateway

Distribute, shield, route: and one product often does all three.

Load balancers distribute requests, reverse proxies shield one origin, and API gateways route calls to many services. All three forward requests, and one product such as NGINX can do all three jobs. The job you need done is what decides which one you are adding, and what you call it in the design.

The three intermediaries on four axes
Axis	Load balancer	Reverse proxy	API gateway
Behind it	Copies of one server	One origin	Many different services
Main job	Spread load, skip failed copies	TLS, caching, hiding the origin	Route by path, authenticate, limit
Routes on	Health and an algorithm	Nothing to choose; one destination	Path, method, caller
Typical products	AWS ALB and NLB, HAProxy	NGINX, Cloudflare	Amazon API Gateway, Kong

What does the system need in front of its servers?

When Several identical copies must share the traffic
, choose
A load balancer
When One server must not face the internet, or needs TLS and caching done for it
, choose
A reverse proxy
When Many services share callers, and every call needs the same checks
, choose
An API gateway

Otherwise A single server with modest traffic can face the internet through a managed service that does TLS for it, and needs none of the three yet.

When they combine. A real system often stacks them: a gateway routes /orders to the orders service, and a load balancer spreads those calls across its four copies. Each layer is there for its own job.

So name each intermediary by the job it does in your design, because the product name alone does not tell a reader why it is there.

← → move through sections and cards