Reverse proxies and gateways
One front door that handles the boring, repeated work before anything reaches your code.
What problem does reverse proxies solve?
A reverse proxy sits in front of your servers and receives every request first. Clients talk to it, and it talks to your services. It gives you one place to do the work that every service would otherwise repeat.
That work is: handling HTTPS, compressing responses, serving static files, rate limiting, checking logins, routing by path, and logging.
What reverse proxies costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for reverse proxies, and when not to
Use it when
- Anything that should happen the same way for every request: TLS, compression, request logging, rate limits.
- Putting several services behind one domain, routed by path.
- Hiding your internal layout from the outside world.
- Serving static files, so application servers never see those requests.
Do not, when
- Business logic. Once routing rules start expressing product decisions, you have a distributed system living in a config file.
- A single service with nothing shared to do. Then it is a hop for nothing.
How reverse proxies actually works
People get asked how a reverse proxy differs from a load balancer. They overlap a lot, and the same software usually does both. The difference is purpose. A load balancer exists to spread traffic across several identical servers. A reverse proxy exists to be a front door, and it is useful even with one server behind it, because it still handles TLS and serves static files. In practice nginx, Envoy and most cloud load balancers do both jobs. Say that, rather than pretending they are separate boxes.
An API gateway is a reverse proxy with stronger opinions. It checks logins, applies per-customer rate limits, reshapes requests, and often combines several backend calls into one response. It is the natural home for the things every public API needs. The risk is that it grows until it holds business logic, and then deploying anything means deploying the gateway.
A forward proxy is the mirror image, and it deserves one sentence so the names do not confuse you. It sits in front of *clients* rather than servers. It is what a company uses to control and inspect traffic leaving its own network.
Two things catch people out. First, if TLS ends at the proxy, then traffic behind it is plain HTTP. That is fine inside a trusted network and not fine across the public internet, so know which one you have. Second, the proxy is where the client's real IP address gets lost. That is why X-Forwarded-For exists, and why rate limiting by IP breaks if you forget to read it. Trust that header only when your own proxy set it, because clients can send it too.
- Forgetting the proxy needs a backup of its own. It is now in front of everything.
- Losing the client IP, then rate limiting every user as if they were one person.
- Letting the gateway collect business logic until it is the riskiest deploy you have.
The reverse proxies follow-up an interviewer will ask
"What is the difference between a reverse proxy and a load balancer?"
Mostly framing, and the same software usually does both, which is worth saying instead of inventing a clean split. A load balancer exists to spread traffic across several identical servers, and it is meaningless with one server. A reverse proxy exists to be a front door: handling TLS, compressing, serving static files, applying rate limits, routing by path. That is useful even with a single backend. So the way I think about it is that load balancing is one feature a reverse proxy usually has. In a design I would draw one box and say what it does, rather than draw two boxes to satisfy a vocabulary question. And I would remember to run more than one of them, because whatever I call it, it is now in front of everything.
Your turn
Name three things worth doing in a reverse proxy rather than in each service, and one thing that should not go there.
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- nginx — HTTP Load Balancing ↗The configuration for the thing this page describes, from the most widely deployed implementation.