Reverse Proxy

When servers were exposed to the internet directly, every service came with its own address. Run the document service on port 3000 and the search service on port 4000, and there are two addresses to tell users about. Five services means five.

Addresses weren't the only thing multiplying. Encryption certificates went into each service separately, so renewal meant touching five places every three months, and the rules about who is allowed in got written out five times with the same content. Miss one and that service alone sits quietly open, and nothing in the system reports that it happened. Deployment caught on it too: because the server's address was known to clients, moving a server to new hardware meant telling users the address had changed.

A reverse proxy solves that by standing one layer in front. Every request from outside lands on this one place, which then forwards it to a server behind. Users don't know how many servers there are or where they live. Proxy means stand-in, and this one is the reverse of the ordinary kind that stands in for the client — this one stands in for the servers. From the client's point of view the proxy is the application, and everything behind it is an implementation detail.

Everything else follows from collapsing the entrance into one place.

1. There is one entrance. Users know a single address, and the proxy picks the backend by looking at the path: /api goes to the document service, /search to the search service. Adding a service means nothing has to be announced to users, and nothing in their bookmarks breaks.
2. The backends are hidden. Internal addresses and port numbers aren't visible from outside, so the attack surface shrinks to the proxy alone. The servers behind can be closed to external connections entirely, which turns a whole class of misconfiguration into something that can't reach them.
3. Encryption terminates in one place. Put the certificate for Transport Layer Security (TLS), the standard that encrypts a connection in transit, on the proxy only, and renewal is one job. Between the proxy and the servers behind it, traffic runs on an internal network and can travel unencrypted, so the backends don't deal with encryption at all.
4. Shared work happens out front. Caching, which stores a result once produced so it can be reused, rate limiting, which caps how many requests are accepted in a window, response compression, and access logging all attach here. Instead of the same code in five services, it's configuration in one place, and changing a rule means deploying one thing.
5. Backends change without disturbing the front. Moving a server to new hardware or adding machines means editing only what the proxy points at. The address users hold stays the same, which is what makes replacing hardware during business hours possible at all.

Several parts share the idea of standing one layer in front, so the choice comes down to how much that layer does.

1. A load balancer exists to spread requests across several servers. Real tools usually do both jobs, which is why the names get used interchangeably — but a reverse proxy earns its place with one server behind it, and a load balancer does not.
2. An API gateway collapses several services into one entrance while also handling authentication, per-plan usage limits, and versioning of the contract. It's the thicker layer that contains what a reverse proxy does, used by products that open a door to outside developers.
3. A content delivery network (CDN) serves assets like images and scripts from a location near the user. It sits further forward than the proxy, handling static assets first and letting the rest through.
4. You can also skip the layer and divide with Domain Name System (DNS), the system that turns domain names into addresses, giving each service its own name pointing straight at its server. Nothing to install makes it the simplest option, and it gives up all five items above. It stays reasonable for a single service with one certificate and no shared rules to enforce.

"We can catch this in the reverse proxy config, so the service code doesn't need touching."

A judgment that this is shared work and ends at the front layer.

"The certificate lives only on the proxy, so the servers behind receive plaintext."

Confirming where encryption terminates and where it stops being necessary.

"If there's only one proxy, everything dies when it dies."

Pointing at the single point of failure created by collapsing the entrance.

At Pagedeck, Theo added this layer after splitting into three services. Before that, documents, search, and notifications each answered at a different address, and certificate renewal came around three times every three months. One renewal on the search side got missed, browsers threw a warning, and 40 support tickets arrived that day — all of them about a certificate nobody had a calendar reminder for.

After the proxy went in, one certificate replaced three. With backends split by path, adding a fourth service came down to one more line in the proxy configuration, a change that shipped in an afternoon instead of needing a new domain and a new certificate. The trade was a structure where everything stops if the proxy stops, so the team moved to two proxies with either one able to take the traffic.

The most common mistake is treating a proxy and a reverse proxy as the same thing. The names are nearly identical and both relay traffic. What's reversed is who they stand in for. An ordinary proxy sits on the user's side, standing in for users — the box inside a company that funnels and filters employee traffic. A reverse proxy sits on the server side, standing in for servers. Confuse the two and firewall rules get written facing the wrong direction, which opens what was supposed to be closed.

Reading the extra layer as automatically faster is the other one. Caching and compression happen out front, which makes it look that way. But requests now take one more hop, and that hop costs latency. On requests the cache answers, the gain is far larger; on requests that have to reach a backend anyway, it is slower than having no proxy at all. And with one entrance, everything stops when the proxy stops. The decision to add a front layer comes with the decision to run more than one of it, which is a cost worth naming before the layer goes in rather than after the first outage.