← System Design Hub
System Design · Guide

Reverse Proxy

Edge routing, TLS, caching, request forwarding.

— min read System Design

Theory

Reverse Proxy: Edge routing, TLS, caching, request forwarding.

A reverse proxy sits between clients and backend servers, accepting requests on behalf of the backends. Unlike a forward proxy (which clients configure to proxy their outbound traffic), a reverse proxy is transparent to clients — they send requests to a single hostname and the proxy routes, caches, terminates SSL, and load-balances behind the scenes.

SSL/TLS termination is one of the primary jobs: the proxy decrypts HTTPS from clients and forwards plain HTTP to backends. This offloads CPU-intensive TLS handshakes from application servers and centralizes certificate management. The backend receives X-Forwarded-Proto: https and X-Real-IP headers so it knows the original scheme and client IP.

Caching at the reverse proxy layer reduces backend load for idempotent responses. Nginx's proxy_cache, Varnish, or Traefik's in-memory cache store responses keyed by URL. Cache-Control headers from backends control TTL and cache eligibility. Vary: Accept-Encoding tells the proxy to cache separate copies for gzip vs uncompressed clients.

Request routing: a reverse proxy can route by hostname (virtual hosting), URL prefix (/api/ → app servers, /static/ → object storage), or header values. This enables blue/green deployments (route 10% of traffic to new version via weight), A/B testing, and canary releases without changing DNS or client configuration.

Popular implementations: Nginx (event-driven, low memory, config via nginx.conf), HAProxy (high-performance L4/L7, TCP-level stats, ACL-based routing), Traefik (auto-discovers Docker/Kubernetes services via labels, dynamic config without restart), AWS ALB (managed, path/host/header routing, WAF integration, target group weighting for canary).

Connection pooling: the proxy maintains persistent upstream connections (keepalive) and reuses them across many client requests. This eliminates TCP handshake overhead on every request. Nginx: keepalive 64 in upstream block; HAProxy: option http-server-close on backend.

Security: the proxy can enforce rate limiting (limit_req_zone in Nginx), block by IP/country/header, add security headers (HSTS, X-Frame-Options, CSP), and strip sensitive response headers before forwarding to clients. A WAF (Web Application Firewall) is often placed at this layer to filter OWASP Top 10 attacks.

Architecture Diagram

Users / clients
         |
  Reverse Proxy
         |
  Core services
         |
  Data + observability

Examples

bash 
# Reverse Proxy
# Edge routing, TLS, caching, request forwarding.
# Validate in staging before production rollout.

Interview Questions

What problem does Reverse Proxy solve?

It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.

Key components of Reverse Proxy?

Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.

Common production pitfalls?

Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.

How do you test changes safely?

Staging parity, canary/gradual rollout, automated health checks, and documented rollback.

Metrics to prove success?

Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.

Beginner vs advanced concern?

Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.

Best Practices

  • Treat Reverse Proxy config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials.

Common Mistakes

  • Adopting Reverse Proxy without measurable success criteria.
  • No staging environment mirroring production constraints.
  • Missing rollback path during incidents.
  • Undocumented on-call expectations.

Trade-off Analysis

Reverse Proxy improves edge routing, tls, caching, request forwarding. but adds operational and cognitive complexity — justify with load and team size.

Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.

Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.

Document accepted inconsistency windows and recovery behavior before production cutover.

Cheat Sheet

ReverseEdge routing, TLS, caching, request forwarding.
SLOService level objective
RollbackRevert to last known good
CanaryLimited blast-radius rollout
RunbookIncident steps

Practical Exercises

Reverse Proxy sandbox

Stand up Reverse Proxy locally or in free tier; document commands and failure recovery.

Failure drill

Introduce misconfiguration; practice detection and rollback under time limit.

← Load Balancing

Related topics