Uses of Proxies

Uses of Proxies

A proxy is an intermediary server that sits in the request path between a client and a destination server, forwarding traffic on someone's behalf. The word matters: a proxy acts for another party. That single idea splits into two families that interviewers expect you to keep straight. A forward proxy sits in front of clients and represents them to the outside world (think a corporate egress gateway, or your VPN). A reverse proxy sits in front of servers and represents them to incoming clients (think Nginx, HAProxy, Envoy, or a CDN edge). The reason the concept exists is indirection: once every request funnels through a controlled choke point, you can observe, cache, secure, rewrite, and reroute traffic without touching the clients or the origin servers themselves.

How it works, precisely

Mechanically, a proxy terminates one connection and originates another. When a client opens a TCP (and usually TLS) connection to a reverse proxy, the proxy completes the handshake itself, reads the HTTP request, and then makes a separate upstream connection to the chosen backend. This is why a proxy can do TLS termination (decrypt at the edge, keep private keys off the app servers), connection pooling (keep warm keep-alive connections to backends and multiplex many short-lived client connections onto them), and header rewriting (inject X-Forwarded-For, X-Request-ID, strip internal headers).

The core capabilities layered on top of that indirection are:

• Load balancing — distribute requests across backends via round-robin, least-connections, or consistent hashing.
• Caching — store responses (static assets, cacheable GETs) so repeat requests never reach the origin.
• Security / access control — TLS offload, WAF rules, IP allow/deny lists, rate limiting, DDoS absorption, and hiding origin topology.
• Anonymity & filtering (forward) — mask client IPs, enforce corporate egress policy, block categories of sites.
• Compression & protocol translation — gzip/brotli, HTTP/2 or HTTP/3 at the edge while speaking HTTP/1.1 to legacy backends.

A worked scenario

Suppose a news site serves 50,000 QPS at peak. Traffic analysis shows 92% of requests are for cacheable content (article HTML, images, CSS/JS) and only 8% are personalized or write requests. You place a reverse-proxy cache (or a CDN edge, which is a geographically distributed reverse proxy) in front of the origin.

With a 92% cache hit ratio, origin traffic drops from 50,000 QPS to 50,000 x 0.08 = 4,000 QPS. If each origin box safely handles ~500 QPS, you go from needing ~100 servers to ~8 — a 12x fleet reduction. Latency improves too: a cache hit served from edge memory returns in ~5-20 ms, versus ~150-300 ms for a full origin round-trip that touches the database. TLS termination at the proxy also saves each backend the ~1-2 ms CPU cost of handshakes and lets you pool, say, 200 warm upstream connections instead of opening a fresh one per client.

Trade-offs — when to use, when not

Reverse proxy vs. a plain L4 load balancer. A reverse proxy operates at L7 (HTTP-aware): it can route by path/header, cache, terminate TLS, and apply WAF rules. An L4 load balancer just forwards packets by IP:port — far cheaper per connection and lower latency, but blind to content. Use L7 when you need routing intelligence or caching; use L4 when you need raw throughput for non-HTTP or already-encrypted passthrough traffic.

Reverse proxy vs. API gateway. An API gateway is a specialized reverse proxy with authn/authz, per-consumer rate limits, request transformation, and billing. Reach for a gateway at an API's public edge; a plain reverse proxy suffices for internal fan-out and static caching.

Proxy caching vs. a dedicated cache (Redis/Memcached). Proxy caching is transparent and keyed by URL — great for whole HTTP responses. An application cache stores arbitrary objects your code looks up explicitly, giving fine-grained control at the cost of app complexity. They compose: CDN for responses, Redis for hot data.

When NOT to add a proxy: if traffic is low, uncacheable, or latency-critical, an extra hop just adds ~1-5 ms and one more thing to operate. For a single backend with no TLS/caching/routing needs, a proxy is over-engineering. And a naively single reverse proxy is a single point of failure — you must run it redundantly, which raises operational cost.

Pitfalls an interviewer probes

• Losing the real client IP. Once the proxy terminates the connection, backends see the proxy's IP. You must forward X-Forwarded-For / use PROXY protocol, and backends must trust it only from the proxy — otherwise clients can spoof their IP and defeat rate limiting.
• Cache correctness. Caching authenticated or personalized responses leaks one user's data to another. Honor Cache-Control, Vary, and cookies; never cache Set-Cookie responses blindly. The mechanism: Vary tells the cache which request headers are part of the cache key — Vary: Cookie means a per-user response is stored per user instead of leaking across users; a missing Vary is the leak.
• The proxy as SPOF and bottleneck. All traffic flows through it, so it needs redundancy (multiple instances behind DNS/anycast), health checks, and enough connection capacity. TLS termination concentrates CPU there.
• Thundering herd / cache stampede. When a hot key expires, many requests miss simultaneously and hammer the origin. Mitigate with request coalescing (single-flight) and stale-while-revalidate. Coalescing = the proxy keeps one in-flight fetch per key and attaches concurrent misses as waiters — traced step-by-step (including the failure branch) in What is a Proxy Server. Stale-while-revalidate serves the expired copy while refreshing in the background; the one-line rule from the fleet deep-dive's cache-consistency section: SWR for latency-tolerant staleness, blocking revalidation (strong read-through) where a stale read has a concrete cost.
• Timeout and retry storms. Aggressive proxy retries against a struggling backend can amplify load and cause cascading failure. Bound retries and use circuit breakers.
• Head-of-line & buffering. Buffering large request/response bodies at the proxy adds latency and memory pressure; streaming vs. buffering is a real config choice.

Key takeaways

• A proxy is indirection in the request path: forward proxies front clients, reverse proxies front servers, and both unlock caching, security, load balancing, and traffic control at a single choke point.
• The mechanism is connection termination + re-origination, which is what enables TLS offload, connection pooling, and header rewriting.
• Choose by need: L4 LB for raw passthrough, reverse proxy for L7 routing/caching, API gateway for authn and quotas, Redis for explicit object caching — they compose rather than compete.
• Interviewers probe the failure modes: preserving client IP, cache correctness (Vary/auth), SPOF/redundancy, and cache stampede — a proxy is only as good as its operational hardening.