These three terms get used interchangeably, and it does not help that a single Nginx config can be any of them. The confusion is understandable: from the outside they are identical. One address accepts requests and something else answers them.

The distinction is not in the front. It is in what is behind it.

flowchart LR
    C[Client] --> E[Single entry point]
    E -->|reverse proxy| B1[One backend]
    E -->|load balancer| B2[M copies of one backend]
    E -->|API gateway| B3[N different backends]

That is the entire taxonomy. Everything else is detail.

Reverse proxy — one backend

One entry point, one service behind it. The proxy exists to do something to the request on the way through: terminate TLS, check credentials, rewrite a header, serve a cached response.

The canonical use is exposing something that cannot be exposed directly. A machine on 192.168.0.12 is firewalled off from the internet; a machine on a public address accepts connections and forwards them inward. Clients only ever talk to the public one and generally have no idea the other exists.

The value is interposition. You have a place to put behaviour that belongs in front of the service rather than inside it.

Load balancer — many copies of one backend

One entry point, M identical instances behind it. Now the job is distribution: spread requests across the copies by some policy — round robin, least connections, weighted if the machines differ.

This is the horizontal scaling primitive. You add capacity by adding instances, and the balancer is what makes them look like one address to the outside world.

Two things usually come with it. Health checks, so an instance that stops responding is taken out of rotation rather than continuing to receive a third of your traffic. And session affinity, so a client that needs to keep hitting the same instance can — though needing that at all is usually a sign of state living somewhere it should not.

API gateway — many different backends

One entry point, N distinct services behind it. The gateway now has to route on the content of the request, because the backends are not interchangeable: /users goes to one service, /orders to another.

Once you are inspecting requests to route them, it is cheap to do other things at the same time, and gateways accumulate features accordingly — authentication, rate limiting, quotas, request and response transformation, API key management, per-consumer policy.

That is the real difference from a load balancer. A load balancer forwards; a gateway forwards and enforces. It is the natural home for policy that would otherwise be reimplemented in every service.

Why one piece of software can be all three

Nginx can forward to one backend, balance across several copies, or route by path to different services. So can Envoy, HAProxy, and Traefik.

The category is determined by the topology you deploy, not the binary. Asking "is this a reverse proxy or a load balancer" is asking about your architecture, not your software choice.

Cloud products blur it further. AWS Application Load Balancer does content-based routing, which is a gateway behaviour. CloudFront is a CDN that is also a caching reverse proxy. API Gateway is a managed gateway that also balances. The labels are marketing; the topology is what you should reason about.

NOTE

Caching is worth separating out from all of this. It is a feature some implementations offer, not a property of any of the three categories — a reverse proxy may cache, a gateway may cache, a plain load balancer usually does not. Whether caching is available is a question about the specific product, not about which of these three shapes you have drawn.

How this shows up in practice

The three tend to arrive in order as a system grows:

One machine, firewalled. A public host forwards to it. Reverse proxy.

Traffic outgrows one machine. A second identical instance appears, and the forwarder starts distributing between them. Load balancer.

Auth and rate limiting need doing. Implementing them in every service means implementing them inconsistently, so they move to the front. API gateway.

Each step adds a capability the previous one lacked, and none of them requires replacing the software — usually just extending its config.

Which is why the terms get muddled. They are not three different tools. They are three points on one line, and most systems walk along it.