Reverse Proxies: The Smart Front Door for Your Servers

In the last chapter a load balancer sat in front of our servers and spread traffic. A reverse proxy sits in the same spot but wears more hats — it's the smart front door to a system, handling encryption, routing, caching, and protection. The terms overlap enough to confuse people, so let's draw the lines clearly and see what this front door actually does.

What a reverse proxy is

A reverse proxy is a server that sits between clients and your backend servers, receiving every incoming request and forwarding it on. Clients connect to the proxy and never talk to your real servers directly.

Client

↓→

Reverse proxy

↓→

Backend server

That single position — in front of everything — is what makes it so useful. Because all traffic flows through it, it's the natural place to handle cross-cutting jobs you'd rather not duplicate across every backend server.

Reverse vs forward proxy

The word "proxy" appears in two opposite roles, and the difference is simply whose side it's on:

This guide is about the reverse kind — the front door to your system.

The jobs a reverse proxy does

Because it's the single entry point, a reverse proxy is the right home for several jobs at once:

Job	What it does
TLS termination	Decrypts incoming HTTPS so backends don't each handle certificates
Routing	Sends requests to different backends by path or hostname
Load balancing	Spreads traffic across a pool (the previous chapter's job)
Caching	Serves common responses without hitting a backend
Compression / buffering	Shrinks and smooths responses to clients

Two of these are worth a closer look.

TLS termination. Encrypting traffic with HTTPS is essential but fiddly — certificates, key management, the handshake. Handling it on every backend server is wasteful and error-prone. Instead, the reverse proxy decrypts HTTPS once at the edge and talks plain (within your trusted network) to the backends. Certificates live in one place.

Routing. In a system with multiple services, the reverse proxy is what sends each request to the right one — /api/... to the API servers, /images/... to an image service, a different hostname to a different app. It's the dispatcher at the front of a multi-service architecture, which is why it's central to microservice setups.

A shield for your backends

A quieter but important benefit: the reverse proxy is a protective layer. Your backend servers never face the public internet — clients can only reach the proxy, and the proxy decides what gets through.

This is a recurring theme in system design: funnel traffic through a controlled front door so you can secure, observe, and manage it in one place.

It overlaps with the load balancer

By now you've noticed that a reverse proxy and a load balancer sound a lot alike — and in practice they're often the same piece of software, just emphasizing different jobs:

• A load balancer emphasizes distributing traffic across servers.
• A reverse proxy emphasizes the broader set of front-door jobs — TLS, routing, caching, protection — of which load balancing is one.

Don't get hung up on the labels. The useful question isn't "is this a load balancer or a reverse proxy?" but "what jobs does my front door need to do?" One component frequently does several of them.

Recap

• A reverse proxy sits in front of your servers, receiving all client requests and forwarding them on.
• It differs from a forward proxy by whose side it's on — reverse fronts servers, forward fronts clients.
• It's the natural home for TLS termination, routing, caching, and load balancing — cross-cutting front-door jobs.
• It shields backends, which can stay on a private network with the proxy as the one controlled entry point.
• It overlaps with the load balancer — often the same software; focus on the jobs, not the label.

Caching came up as one of a reverse proxy's jobs. Pushing that idea to the network's edge, close to users, gives you a CDN. Continue to Content Delivery Networks.