Reverse Proxy Interview & Revision

A server in front of your application servers that receives every client request on their behalf and forwards it to the right backend, then relays the response. Clients only ever see the proxy. Build the answer up: it's the single edge layer where SSL, static serving, routing, caching, and security live so the backends don't each own them.

Because one Nginx tier solves several problems at once: it terminates HTTPS (one cert surface instead of one per server), serves static files efficiently, routes multiple services under one domain, caches safe responses, and filters hostile traffic — and it can also balance across backends when needed. Answer by walking the problems it removes from the app, not by listing directives.

Both can spread traffic across backends, but a load balancer is narrow and distribution-first, while a reverse proxy is the public-facing HTTP(S) intermediary that can also terminate TLS, cache, serve static, route by path or host, and apply security controls. They're complementary: in production a dedicated LB often sits in front of a cluster of reverse proxies.

An API gateway is a reverse-proxy-based layer specialised for APIs and policy: auth, per-consumer rate limiting, aggregation, transformation, and versioning. A reverse proxy may also route to multiple backends, but its centre of gravity is general edge plumbing for HTTP(S) traffic. Same underlying tech, different responsibilities.

Direction and beneficiary. A forward proxy sits in front of clients and proxies their outbound traffic (the destination server usually does not care that it is there). A reverse proxy sits in front of servers and proxies inbound traffic on their behalf (the client usually only sees the proxy's address). Remember it by who it fronts.

The client negotiates HTTPS with the proxy; the public certificate typically lives on the proxy tier, and the proxy→backend hop may be plain HTTP on a trusted network or HTTPS again if you re-encrypt internally. One public cert surface to rotate instead of one per server.

On a cache hit within the TTL the proxy answers without touching the backend; a miss falls through, then populates the cache. At a high hit ratio the backend sees only a fraction of total traffic. The catch: never cache per-user content under a shared key.

Backends have no public address, so the internet can't reach them directly — the proxy is the only exposed surface. Being the single choke point, it's where you enforce TLS, rate limiting, IP filtering, request limits, and WAF rules, dropping bad requests before any app parses them.

Avoid running just one in production — it's on every request. Run a cluster of identical, stateless proxies behind a dedicated load balancer with health checks, so a failed instance is ejected automatically and the tier scales horizontally.

The proxy forwards by host or URL prefix — /api to the API service, /admin to admin, /static to assets — presenting one domain over several independent backends. This overlaps with API-gateway routing, but without assuming the full API-policy layer.

Static files never change per request, so making an application runtime generate them wastes CPU. The proxy streams them directly from disk or cache and bypasses the backend entirely, freeing the app for dynamic work.

By who they front. Forward proxy: in front of clients, proxies their outbound requests, server unaware. Reverse proxy: in front of servers, proxies inbound requests on their behalf, client unaware.

Often no — HTTPS terminates at the proxy and the internal hop is plain HTTP over a trusted network. In zero-trust environments you re-encrypt that hop (e.g. mTLS).

On a miss: you pay the cache lookup plus the full backend fetch. Caches only win when hits dominate — always measure hit ratio.

Load balancing is one of its jobs. It also terminates SSL, serves static, routes by path, caches, and filters. A dedicated LB is deliberately narrow and fast; the proxy is broad and application-aware.

A gateway usually builds on reverse-proxy behaviour, then adds API policy such as auth, per-consumer rate limiting, aggregation, transformation, and versioning.

It's on every request, so it's a single point of failure — if it dies, SSL, routing, and cache all die with it. Run a cluster behind a load balancer.

A compiled proxy streams files from disk far faster and cheaper than a language runtime, and it bypasses the backend entirely, freeing it for dynamic work.