Reverse proxy
A server that sits in front of your app and forwards requests to it, adding TLS termination, routing, caching, and rate limiting. Clients never see the origin directly. Nginx, Envoy, and CDN edges are all reverse proxies.
- Almost always in front of public services for TLS, routing, and protection.
- Canary and traffic shaping.
- Tiny internal services where the extra hop adds latency for no benefit.
- When you need direct peer-to-peer with a mesh sidecar instead.
Definition
Unlike a forward proxy (which proxies for clients), a reverse proxy proxies for servers. It accepts client connections, applies policies, and forwards to one or more backends, then returns the response.
Why it exists
Apps shouldn't reimplement TLS, routing, compression, caching, and DoS protection. Centralizing these in a proxy keeps application code focused and lets you swap backends independently.
How it works
Listens on 443/80, terminates TLS, inspects the request, routes by host/path to an upstream pool, applies retries/timeouts/limits, and returns. Can buffer responses, cache, or transform headers. Often paired with a service mesh for east-west traffic.
Scaling limits
Stateful proxies (sticky sessions, connection limits) cap out on connection-tracking memory. Per-request header manipulation adds CPU at very high RPS.
Cost shape
Cheap to run; the cost is operational complexity and the proxy as a new failure surface. Managed proxies charge by throughput.
Alternatives
- Service mesh sidecar — Same idea but per-pod for east-west; more resource overhead.
- Direct exposure — Simplest but loses TLS/routing/protection centralization.
Failure modes
- Becoming a single point of failure if not redundant.
- Buffering large uploads and exhausting memory.