The edge gateway abstraction
A reverse proxy sits in front of backend servers and handles client connections on their behalf. Clients connect to the proxy (single public IP), the proxy forwards the request to one of many backends, and the client sees a unified service. The proxy terminates TLS, decrypts the request, inspects it, and decides which backend gets it. Responses flow back through the proxy and are returned to the client. From the client's perspective, there is a single server; the backends are hidden.
Functions performed at the edge
TLS termination (decryption, re-encryption per backend) offloads CPU from backends. Request routing sends requests to different backends based on path (API requests to backend A, static files to a cache server), host header, or user session. Load balancing distributes requests evenly. Caching stores responses from backends and serves repeated requests directly. Request/response modification rewrites headers, adds tracking, or strips sensitive data. Authentication can be enforced at the proxy before reaching backends.
Scaling and isolation benefits
The proxy absorbs connection overhead (many slow clients connecting) and serves from cache or a connection pool to backends, reducing backend load. If a backend dies, the proxy routes around it. Adding backends does not require client-side changes: the proxy balances across the new pool. Security improves: backends do not expose their real IPs, and the proxy can rate-limit or block malicious requests. Debugging becomes easier: the proxy logs every request, providing a single view of all traffic.