In a design discussion one engineer says "put a load balancer in front of it", another says "no, an API gateway", and a third says "it is just a reverse proxy". What actually distinguishes those three roles, and can a single process play all of them?

## Three words, one role The fastest way to lose twenty minutes of a design review is to argue about whether the box is a load balancer or a reverse proxy. They are not competing categories. **Reverse proxy** is the role: an intermediary deployed by the service owner, which the client is unaware of, that terminates the client's connection and opens its own to a backend. Load balancers and API gateways are reverse proxies with different jobs foregrounded. ## Reverse proxy: the base role Stripped to the minimum, a reverse proxy accepts a connection meant for your service and relays it onward. Even with a single backend, that hop is useful: it is a place to terminate TLS, to serve static content, to add or strip headers, to enforce limits, and to swap what is behind it without the client noticing. If there is one backend and no per-caller logic, "reverse proxy" is the honest name. ## Load balancer: the pool is the point Call it a load balancer when the interesting decision is *which member of a pool* serves this request, and everything that follows from having a pool: knowing which members are healthy, choosing among them, deciding whether a given client should keep landing on the same one, and draining a member during a deploy. Those concerns exist whether the box parses requests or merely forwards connections — which is why a purely connection-level balancer is still a reverse proxy in role even though it can never read a URL path. The important consequence is *statefulness*. A pool-aware hop holds health state and, if you add affinity, per-client state. That state is what makes a load balancer something you operate rather than something you merely configure. ## API gateway: the caller is the point Call it a gateway when the interesting decisions are about *who is calling and what they are allowed to do*: authenticating the caller once at the edge, applying a quota or plan, and deciding which of your internal services is exposed under which published path. All of that requires understanding the request, so a gateway is necessarily request-level; you cannot make a connection-only proxy into a gateway. That is also where the real trade lives. A gateway holds knowledge that belongs to the product: which routes exist, who may call them, what a caller's plan allows. Product knowledge changes on the product's cadence, so the edge starts needing releases whenever a service changes — and a mistake there is a mistake for every service behind it. ## One process, several hats The general-purpose proxies overlap almost completely. nginx, HAProxy, Envoy and Caddy can each front a pool, terminate TLS, route by host and path, and enforce limits; several also do authentication and per-caller policy natively or through plugins. In a small system you will genuinely have one process that is simultaneously the reverse proxy, the load balancer and the gateway, and calling it by all three names is not wrong. The difference shows up as systems grow and the roles separate onto different hops — often a connection-level balancer at the front for capacity and failure isolation, a request-level tier behind it for routing, and gateway policy either in that tier or in a dedicated one. ## How to make the distinction useful Replace the noun with a checklist of responsibilities and ask, for each, whether you want it *here*: - Does this hop pick among several backends, and does it need health state to do it? - Does it need to read the request — path, method, headers — or only the connection? - Does it terminate TLS, and therefore hold a private key? - Does it know who the caller is, and enforce anything per caller? - Does it hold per-client state such as affinity or counters, and what happens when it restarts? - Who deploys a change to it, and how quickly, and what is the blast radius if that change is wrong? The answers, not the label, determine the design. Two hops that answer the checklist identically are the same thing whatever the vendor calls them. ## The failure mode of arguing about names When a team insists on a gateway product because "we need a gateway", the usual outcome is a second hop that duplicates the routing the first hop already does, adds latency, and splits ownership of routing across two teams. When a team insists on "just a reverse proxy" and then bolts per-caller quotas onto it by hand, they have built a gateway without admitting it, and without the operational tooling one usually brings. In an interview, say the three words describe emphasis rather than product, name the responsibilities that actually differ, and then show that you would decide by responsibility and ownership rather than by label.