Load Balancer vs Reverse Proxy

Difficulty: Intermediate

Question

What is the difference between a load balancer and a reverse proxy? Explain layer 4 versus layer 7 balancing and common algorithms.

Answer

These two terms are used almost interchangeably, and interviewers know it, so they want to see whether you understand the overlap and the distinction. First, forward versus reverse proxy. A forward proxy sits in front of clients and makes requests on their behalf to the internet (a corporate proxy or a VPN-ish setup); the server sees the proxy, not the client. A reverse proxy sits in front of servers and receives requests on their behalf; the client sees the proxy, not the backend. Nginx, HAProxy, Envoy and Traefik are typical reverse proxies.

A reverse proxy is defined by its position and by the things it can do for the backend: TLS termination (decrypt once at the edge, plain HTTP internally), caching, compression, request routing by path or host (send /api to one service and /static to another), rate limiting, authentication, header rewriting, and hiding the topology and IPs of the backend servers. A load balancer is defined by its purpose: distributing traffic across multiple backend instances for scalability and availability, with health checks that remove dead servers. A load balancer is essentially a reverse proxy with more than one upstream, and most reverse proxy software includes load balancing. So the neat answer is: every load balancer of the proxy type is a reverse proxy, but a reverse proxy in front of a single server is not really balancing anything.

Layer 4 versus layer 7 is the second half of the question. A layer 4 (transport) load balancer looks only at IP addresses and TCP or UDP ports. It forwards connections without reading the payload, so it is very fast, protocol agnostic and can even preserve encrypted traffic end to end. AWS Network Load Balancer and LVS work this way. A layer 7 (application) load balancer understands HTTP: it can route by URL path, host header, cookies or headers, do TLS termination, rewrite requests, retry failed requests, and do canary or blue-green routing. It is more flexible but costs more CPU. AWS Application Load Balancer and Nginx are examples.

Algorithms: round robin cycles through servers in order; weighted round robin gives bigger servers more traffic; least connections sends to the server with the fewest active connections, good for long-lived requests; least response time considers latency; IP hash or consistent hashing sends the same client or key to the same server, which helps caching and stickiness. Power of two choices picks two random servers and takes the less loaded one, cheap and surprisingly effective.

Sticky sessions (session affinity) pin a user to a backend via a cookie or IP hash, which is a workaround for apps that keep session state in memory, but it makes load uneven and breaks when the server dies; the better design is stateless servers with shared session storage. Health checks (active probes to /health and passive tracking of errors) remove unhealthy nodes and prevent sending users to dead ones. Connection draining lets in-flight requests finish before a node is removed during deploys.

The load balancer itself must not be a single point of failure, so production setups run pairs with a floating virtual IP (VRRP, keepalived) or use managed cloud load balancers, or spread across zones. At internet scale you also see DNS load balancing and anycast in front of regional load balancers. Because the backend sees the proxy's IP, the real client address is passed in X-Forwarded-For or via the PROXY protocol, and applications must trust it only from the proxy.

Code examples

Nginx as reverse proxy and load balancer

upstream api_backend {
    least_conn;
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080;
    server 10.0.1.13:8080 backup;
}

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

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
    }
}

TLS is terminated here, the path /api/ is routed to a pool that uses least connections, and the third server is only used if the others fail.

Key points

• Reverse proxy fronts servers; forward proxy fronts clients.
• L4 balances on IP and port; L7 balances on HTTP content.
• Health checks remove failed backends automatically.
• Prefer stateless servers over sticky sessions.

Concepts covered

Load Balancer, Reverse Proxy, Layer 4 vs Layer 7, Health Checks, Sticky Sessions