Proxy Server

Cause → effect chain:

• Without a proxy, every client talks directly to the origin → the origin's real IP is exposed, every client must be reachable by the origin, and there's no shared place to cache, filter, or balance traffic.
• Insert a proxy → it becomes a single control point the architecture can attach behavior to: caching, access control, TLS termination, rate limiting, logging, and routing all live in one place.
• Concrete: a proxy fronting 10 backend servers lets you add a new backend, block an IP range, or rotate a TLS cert once at the proxy instead of on 10 machines.

Trade-off / cost: you've added a network hop (typically sub-millisecond to ~1 ms within a datacenter; more if it terminates TLS or queues) and a new component that can fail. The proxy is now on the critical path, so it must be made highly available (redundant instances behind a VIP/DNS) or it becomes a single point of failure.

The side it represents is the whole distinction:

• Forward proxy → sits in front of clients and acts on their behalf, configured by the client side. The origin server sees the proxy's IP, not the user's. Example: a company routes all employee traffic through a proxy to filter sites and hide internal IPs. client → forward proxy → internet → server.
• Reverse proxy → sits in front of servers and acts on their behalf, configured by the server owner. The client thinks it's talking to the real server; it's actually hitting the proxy. Example: Nginx/Cloudflare in front of your backend doing TLS termination and load balancing. client → internet → reverse proxy → server pool.

Memory hook: a forward proxy hides the client from the server; a reverse proxy hides the servers from the client.

Trade-off / cost: a forward proxy only governs clients configured (or forced via network policy) to use it — clients with another route can bypass it. A reverse proxy must scale with all inbound traffic and becomes the public face of your whole system, so its capacity and availability bound the entire service.

Step-by-step mechanism:

• 1. Accept: client opens a connection to the proxy's public IP and sends GET /page.
• 2. Terminate / inspect: if TLS is terminated here, the proxy decrypts, reads the request, and can apply rules (auth, rate limit, routing by path/host).
• 3. Forward: the proxy opens its own connection to a chosen backend and replays the request. The backend now sees the proxy's IP as the source — the original client IP is preserved only if the proxy adds an X-Forwarded-For header (or uses the PROXY protocol).
• 4. Relay: backend responds → proxy receives it → proxy returns it to the client over the original client↔proxy connection.

So there are two separate TCP connections (client↔proxy and proxy↔backend), which is what lets the proxy pool and reuse backend connections across many clients instead of opening one per client.

Trade-off / cost: terminating TLS means the proxy sees plaintext — it's now a high-value target and must be secured. And because the backend sees the proxy IP, naive IP-based logging/rate-limiting on the backend breaks unless it reads X-Forwarded-For — which is client-spoofable unless the proxy overwrites it and the backend only trusts the value set by that known proxy hop.

Cause → effect with numbers:

• Without caching: 1,000 requests → 1,000 trips to the backend. If the backend takes 50 ms to serve the image, the backend does 1,000× the work and each user waits ~50 ms (plus network).
• With proxy caching: the first request is a miss (~50 ms, fetched from backend and stored). The next 999 are hits served from the proxy's memory/disk in ~1–2 ms.
• Effect: backend load for that asset drops from 1,000 requests to 1 request (a 99.9% reduction), and latency for the cached asset falls from ~50 ms to ~1–2 ms.

This is exactly how a CDN works — it's a globally distributed reverse-proxy cache placed close to users.

Trade-off / cost — staleness: if you update the logo, the proxy keeps serving the old one until its TTL expires. You now must manage cache invalidation (TTLs, cache-busting URLs like logo.v2.png, or explicit purges). Also beware the cache stampede: when a hot key's TTL expires, many concurrent requests miss at once and all hit the backend together — mitigated by request coalescing (one request fetches while the rest wait) or staggered/jittered TTLs.

For an L7 (HTTP) balancer, largely true — the proxying mechanism is the same, the selection logic is the addition:

• A plain reverse proxy forwards every request to one configured backend.
• A load balancer is a reverse proxy that, on each request, picks a backend from a pool using an algorithm — round-robin, least-connections, or hashing on a key.
• Concrete: with 3 healthy backends and round-robin, requests go 1→2→3→1→2→3… When the proxy's health check finds backend 2 failing, it's removed from the pool and traffic splits across the remaining 2, so a dead server stops receiving traffic within seconds instead of returning errors.

(Caveat: an L4 load balancer forwards packets/connections rather than terminating and re-issuing HTTP, so it isn't a full reverse proxy — the equivalence holds cleanly at L7.)

Trade-off / cost — session affinity: if a user's session state lives on backend 1, round-robin sends their next request to backend 2, which doesn't have it → the user gets logged out. You then need sticky sessions (hash on user/cookie so they always hit the same backend), but stickiness skews load distribution and complicates failover (a downed backend loses its users' state anyway). The clean fix is to make backends stateless (store sessions in shared Redis), which is why "keep your servers stateless" is a recurring interview answer.

Reach for the cost side of the ledger:

• Ultra-low-latency / latency-sensitive paths: every proxy hop adds a small but real delay plus a buffering/serialization step. For a high-frequency trading feed or a real-time game's hot loop, even sub-millisecond overhead and added jitter can be unacceptable — you want direct connections.
• Tiny / single-server systems: if you have one backend and no caching, security, or balancing need, a reverse proxy adds an operational component to monitor, patch, and keep available for zero functional gain. It's premature infrastructure.
• End-to-end encryption requirements: if a TLS-terminating proxy would decrypt traffic it shouldn't see (e.g. zero-trust or regulated payloads), the proxy becomes a compliance liability; you'd use a pass-through/TCP (L4) proxy that never decrypts — giving up the inspection and caching features that require plaintext.

Rule of thumb: add a proxy when you need a shared control point (cache, balance, secure, route) across many backends or clients. If you can't name the specific job it does, the extra hop, the extra failure mode, and the extra ops burden aren't justified.

The difference is the layer they operate at and what they cover:

• Proxy = application-layer (L7), usually per-app. It intercepts traffic for a specific protocol/app (e.g. just your browser's HTTP via a configured proxy setting). Other apps on the machine still go direct. A plain HTTP proxy does not by itself encrypt the link between you and the proxy.
• VPN = network-layer (L3), system-wide. It creates an encrypted tunnel that captures all the device's IP traffic — every app, every protocol — and routes it through the VPN server.

Why a proxy isn't a privacy substitute: it leaves non-proxied apps and protocols (DNS, other ports) exposed, and unless it's an encrypting tunnel the hop to the proxy can be observed on the local network. A VPN's encryption and full-device capture close both gaps. (Note: HTTPS still encrypts the payload either way; the distinction is about which traffic is tunneled and whether the link to the intermediary itself is encrypted.)

Trade-off / cost: a VPN's system-wide encrypted tunnel adds per-packet crypto overhead and routes everything through one server, which can reduce throughput and add latency, and it's an all-or-nothing path. A per-app proxy is lighter and selective but offers weaker, narrower protection. Choose by goal: selective app routing/filtering → proxy; full-device confidentiality → VPN.