Reverse Proxy — Part 3: Interview Q&A

maang.io System Design Series

---

What is this?

Parts 1 and 2 built the concierge and showed you behind the desk. This part is the mock interview. We'll walk through the questions you'll actually get, and for each one I'll show you three things: what the interviewer is really probing for, a model answer in plain language, and the senior line — the one sentence that signals you've operated this stuff, not just read about it.

The one-line idea: anyone can say "put a reverse proxy in front of it." What gets you hired is reasoning about the consequences — what the proxy hides, what it costs, and what happens when it breaks.

Read these as a conversation, not flashcards. The phrasing matters as much as the facts.

---

Q1: What's the difference between a forward proxy and a reverse proxy?

What they're really asking: This is the screening question. They want to know if you actually understand proxies or just memorized "NGINX is a reverse proxy." Get the direction right and you've passed; fumble it and they worry about everything else.

Model answer: "Both are middlemen, but they act for opposite parties. A forward proxy acts for the client — it sits in front of users and reaches the internet on their behalf, hiding the clients from the servers they visit. A corporate web filter or a VPN is a forward proxy. A reverse proxy acts for the server — it sits in front of backends and receives requests on their behalf, hiding the servers from the clients. NGINX in front of a web app, or Cloudflare in front of a site, is a reverse proxy. The trick is to ask which side is being hidden: clients for forward, servers for reverse."

The senior line: "Same box, opposite ends of the connection — 'reverse' just means it's on the server side of the wire, which is the reverse of where you'd first picture a proxy."

---

Q2: What's the difference between a reverse proxy and a load balancer?

What they're really asking: This trips up most candidates because the two overlap so much. They want to see whether you understand that it's a category-and-specialization relationship, not two unrelated things.

Model answer: "A load balancer is a specialized reverse proxy. Both sit in front of backends and forward traffic. The difference is emphasis. A pure load balancer's whole job is distribution — spread connections across identical servers, often at Layer 4 where it doesn't even read the HTTP, so it's blazing fast and protocol-agnostic. A reverse proxy is the broader concept: it also does routing by path and host, TLS termination, caching, compression, and security — the load balancing is just one of its hats. In practice, NGINX and Envoy are reverse proxies that include load balancing, while a cloud L4 load balancer just distributes."

The senior line: "Every load balancer is a reverse proxy, but not every reverse proxy is just a load balancer — distribution is one feature of a box that also routes, caches, terminates TLS, and shields the origin."

---

Q3: What problems does a reverse proxy actually solve?

What they're really asking: Can you justify the box, or do you just add it by reflex? They want the why, ideally framed around doing work once instead of in every backend.

Model answer: "It collapses a pile of cross-cutting concerns into one layer at the front door. TLS termination — decrypt and manage certs once instead of on every server. Routing — one public endpoint fans out to many microservices by path or host. Caching and compression — answer hot requests without touching a backend, and gzip/Brotli responses once at the door instead of in every service. Security — rate limiting, a WAF, and origin-hiding so attackers can't even find the real servers. Load balancing — spread traffic across a healthy pool. The unifying principle is separation of concerns: the proxy owns infrastructure, so application code can own business logic."

The senior line: "Its real value is the boundary — backends become private, simple, and swappable, while clients get one stable address that never changes as servers come and go."

---

Q4: Why use NGINX as a reverse proxy? How would you configure one?

What they're really asking: Have you touched the actual tooling, or is this all theory? A few lines of real config proves it.

Model answer: "NGINX is the default because it's fast, battle-tested, and configured with plain text. The minimal setup is an upstream block for the backend pool and a server block that terminates TLS and routes:

upstream app { server 10.0.0.11:8080; server 10.0.0.12:8080; }

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/example.key;

    location /api/ {
        proxy_pass http://app;
        proxy_set_header X-Real-IP $remote_addr;   # forward the real client IP
    }
}

The upstream is the hidden backend pool, listen 443 ssl does TLS termination, and location /api/ is the routing. The gotcha I'd call out is X-Real-IP — once a proxy is in the path, backends see the proxy's IP unless you explicitly forward the client's, which silently breaks logging, geolocation, and rate limiting."

The senior line: "The single config line people forget is X-Forwarded-For / X-Real-IP — without it every backend thinks all your traffic comes from one machine, and abuse-blocking stops working."

---

Q5: How do you keep the reverse proxy itself from being a single point of failure?

What they're really asking: You just put a box in front of everything. If it dies, the whole site dies. Do you see that, and do you know the standard fix?

Model answer: "You never run one. The standard pattern is at least two proxies, active-active, with a fast distributor in front of them — often a cloud L4 load balancer or DNS-based failover at the edge. If one proxy dies, the distributor stops sending it traffic and the others absorb the load. For regional resilience you replicate that whole stack across regions and fail over with DNS. The proxies themselves should be stateless so any one can handle any request — no local session state to lose."

The senior line: "The cure for a single point of failure is never 'make it more reliable' — it's 'make it plural,' which means redundant stateless proxies behind a distributor, replicated across zones."

---

Q6: How would you design a reverse proxy layer for very high traffic — say a million requests per second?

What they're really asking: Can you scale this horizontally and reason about the real bottlenecks (TLS, connections, cache hit rate), not just say "add servers"?

Model answer: "Three levers. First, scale horizontally — many stateless proxy instances behind an edge distributor, auto-scaling on CPU and connection count, spread across regions so users hit a nearby one. Second, maximize cache hit rate — push a CDN in front for static content and tune proxy caching aggressively, because every cache hit is a request your backends never see; that's how you turn a million inbound into a fraction reaching origin. Third, optimize the expensive parts — enable HTTP/2 and connection keep-alive, pool upstream connections so you're not paying TCP+TLS setup per request, and offload TLS to dedicated capacity. The mindset is: figure out which station in the pipeline is your bottleneck — usually TLS handshakes or connection churn — and attack that, not the whole thing."

The senior line: "At a million RPS the win isn't more proxies, it's a high cache hit rate plus connection reuse — the cheapest request is the one that's served from cache and never opens a new connection."

---

Q7: How do you implement zero-downtime deploys (blue-green / canary) with a reverse proxy?

What they're really asking: Do you understand that the proxy's routing layer is the tool for safe rollouts?

Model answer: "The proxy controls which backend pool gets traffic, so it's the natural deploy switch. For blue-green, I run the new version (green) alongside the current one (blue), health-check green, then flip the proxy's upstream from blue to green in one move — and flip back instantly if anything's wrong. For canary, I do it gradually: route 5% of traffic to the new pool, watch error rates and latency, then ramp 5% → 25% → 100%. An L7 proxy can even canary by header or cookie, so internal users hit the new version first. The whole point is that the rollback is a config change at the proxy, not a redeploy."

The senior line: "Because the proxy owns routing, a rollback is just shifting weights back — you decouple 'deployed' from 'serving traffic,' which is the whole safety net."

---

Q8: A reverse proxy is suddenly slow. How do you troubleshoot it?

What they're really asking: Do you have a systematic method, or do you flail? They want to see you walk the pipeline.

Model answer: "I'd localize it to a stage in the request pipeline rather than guess. I start with metrics — latency percentiles (p95/p99, not averages), cache hit ratio, backend response time, and the proxy's own CPU and connection counts. Then I narrow:

Symptom	Likely cause	Fix
High TTFB, backends slow	Backend or DB is the bottleneck	Scale/heal backends, check health checks
High TTFB, backends fast	TLS handshakes or connection churn	Enable keep-alive, pool connections, offload TLS
Low cache hit rate	Bad TTLs or a Vary: Authorization killing caching	Fix cache headers
Proxy CPU pegged	Heavy WAF ruleset or HTTP/2 parsing	Tune rules, scale out proxies
Connection timeouts	Upstream connection pool exhausted	Increase pool size, add backends

The discipline is: measure first, find the slow station, fix that one — don't randomly resize everything."

The senior line: "Slowness is always a specific station in the pipeline — TLS, cache, routing, or backend — and the job is to read the metrics to find which one, not to throw hardware at the whole box."

---

Q9: Reverse proxy, API gateway — when do you reach for which?

What they're really asking: Do you over-engineer? They want to see you pick the least complex tool that fits.

Model answer: "Same family, different sophistication. A reverse proxy is the general front door — TLS, routing, caching, basic rate limiting — and it's where most web apps should start. An API gateway is a reverse proxy with API-specific brains: per-API authentication (OAuth, JWT, API keys), versioning, quotas, request/response transformation, and detailed analytics. I reach for a gateway when I'm exposing APIs to external or third-party developers and genuinely need that management layer. If I just need to route and cache for my own app, a plain reverse proxy is lighter and has fewer moving parts."

The senior line: "Pick the least sophisticated box that does the job — every feature you add at the door is latency and one more thing that can fail, so don't deploy an API gateway to do a reverse proxy's work."

---