Proxies and reverse proxies

Why it matters

Put one component between clients and your servers and you get a place to terminate TLS, route by path, cache responses, enforce rate limits, add headers, and hide how many servers exist or where they are. That component is a reverse proxy, and it is the most reused idea in backend architecture: load balancers, API gateways, CDNs and service mesh sidecars are all reverse proxies with different jobs. Understanding the pattern once explains all of them.

The idea

A proxy is an intermediary that receives requests and forwards them. The direction of trust names the kind.

A forward proxy sits in front of clients and acts on their behalf toward the internet. Corporate networks use it to filter and log outbound traffic; scrapers use it to rotate addresses; a NAT gateway is a forward proxy at the IP layer. The server sees the proxy, not the client.

A reverse proxy sits in front of servers and acts on their behalf toward clients. The client sees one address; behind it may be one server or a thousand. Every public-facing system has one, whether it is called a load balancer, an ingress, a gateway or an edge.

What a reverse proxy does at the edge

1. 1

   Terminate TLS

   Certificates live in one place; backends speak plain HTTP inside the private network, or re-encrypt where the network is untrusted.
2. 2

   Route

   By host, path, header or weight: /api to the API pool, /static to object storage, 5 percent of traffic to the canary.
3. 3

   Protect

   Rate limits per client, request size limits, slow-client buffering so backends never wait on a slow mobile connection, basic WAF rules.
4. 4

   Cache and compress

   Serve cacheable responses without touching a backend; compress text on the way out.
5. 5

   Observe

   One place to log every request, add trace ids, and measure latency per route.

The same idea, three places

An API gateway is a reverse proxy with API-shaped features: authentication, per-consumer quotas, request transformation, versioning. A service mesh puts a small reverse proxy (a sidecar such as Envoy) next to every service so service-to-service calls get mutual TLS, retries, timeouts and metrics without application code. A CDN edge is a reverse proxy distributed to hundreds of cities with a cache attached. Different jobs, one mechanism.

Trade-offs

Every proxy is a hop: latency, a place to misconfigure, a component to scale and keep available. Centralising TLS and policy simplifies services but makes the proxy a critical path that must itself be redundant. Service meshes give consistency across hundreds of services at the price of two extra hops per call and a control plane to operate; a team with ten services usually does not need one.

In an interview

Draw the reverse proxy as the first box after the client and say what it does: "A reverse proxy terminates TLS, routes by path to the right service pool, and enforces per-client rate limits; it is deployed as a redundant pair." If microservices come up, decide explicitly whether a mesh is warranted and say why or why not. Knowing when not to add a layer is the senior signal.