Load Balancer vs Reverse Proxy: Key Differences

TL;DR

Load balancers distribute traffic across multiple servers for availability and scalability, while reverse proxies sit between clients and servers to handle request processing, caching, SSL termination, and security. Modern tools like Nginx and HAProxy blur these lines by offering both capabilities. The key distinction: load balancers focus on where requests go, reverse proxies focus on how requests are handled. In production systems, you’ll often use both—a reverse proxy handling SSL and caching in front of a load balancer distributing to application servers.

Cheat Sheet: Load Balancer = traffic distribution + health checks + failover. Reverse Proxy = request transformation + caching + SSL termination + security. Most production systems use both in combination.

Context

This comparison trips up engineers because modern infrastructure tools have converged—Nginx can load balance, HAProxy can cache, and cloud load balancers offer SSL termination. The confusion is real: when you deploy Nginx in front of your application servers, are you using a load balancer or a reverse proxy? The answer is often “both,” but understanding the conceptual distinction matters deeply in system design interviews and architectural decisions.

The distinction emerged historically: load balancers evolved from hardware appliances (F5, Citrix NetScaler) focused purely on distributing traffic across server farms. Reverse proxies came from web server technology (Apache mod_proxy, Squid) focused on request handling and caching. Today, software-defined infrastructure has merged these capabilities, but the underlying concerns remain distinct. When Netflix routes traffic to thousands of microservices, they need load balancing. When Cloudflare terminates SSL for millions of websites and caches static assets, that’s reverse proxy functionality. Understanding which problem you’re solving determines your architecture.

In interviews, this question tests whether you understand the “why” behind infrastructure components, not just the “what.” Saying “I’ll use Nginx” without explaining whether you need its reverse proxy features (caching, SSL) or load balancing capabilities (traffic distribution, health checks) signals shallow thinking. Senior engineers articulate the specific problem each component solves and justify their layering decisions with concrete requirements.

Side-by-Side Comparison

Feature Comparison Matrix

Dimension	Load Balancer	Reverse Proxy	Interview Insight
Primary Purpose	Distribute traffic across multiple backend servers to prevent overload and ensure availability	Handle and transform client requests before forwarding to backend servers	Interviewers want to hear the core problem each solves—distribution vs. transformation
Key Capability	Traffic distribution algorithms (round-robin, least connections, IP hash), health checking, automatic failover	SSL termination, request/response modification, caching, compression, authentication	Load balancers answer “which server?”; reverse proxies answer “how should I handle this request?”
Minimum Servers	Requires 2+ backend servers to be meaningful (though can work with 1 for future scaling)	Useful even with a single backend server for caching, SSL offloading, security	This is the clearest distinction: reverse proxies add value to single-server deployments
Layer Focus	Can operate at Layer 4 (TCP/UDP) or Layer 7 (HTTP/HTTPS)—see Layer 7 Load Balancing for application-layer details	Primarily Layer 7 (application layer) to inspect and modify HTTP requests/responses	Layer 4 LBs are pure traffic routers; Layer 7 LBs and reverse proxies both inspect application data
Caching	Typically no caching (pure traffic distribution)	Core feature: cache static assets, API responses, reducing backend load	If caching is a requirement, you need reverse proxy functionality
SSL Termination	Modern LBs offer this, but it’s a secondary feature	Primary use case: decrypt once at the edge, forward plain HTTP internally	Both can do SSL termination, but reverse proxies excel at certificate management and cipher optimization
Request Modification	Limited (can add headers like X-Forwarded-For)	Extensive: rewrite URLs, modify headers, inject authentication, compress responses	Reverse proxies are request/response middleware; load balancers are traffic routers
Session Persistence	Core feature (sticky sessions, session affinity)	Can implement, but not the primary concern	Load balancers own session routing; reverse proxies can support it but focus on request handling
Health Checking	Sophisticated active/passive health checks, automatic removal of failed servers	Basic health checks, but not the primary focus	Load balancers continuously monitor backend health; reverse proxies assume backends are available
Example Tools	AWS ELB/ALB, Google Cloud Load Balancer, HAProxy (LB mode), Nginx (LB mode)	Nginx (reverse proxy mode), Apache mod_proxy, Varnish, Squid, HAProxy (proxy mode)	Nginx and HAProxy appear in both columns—they’re Swiss Army knives that do both
Typical Placement	Between internet and application tier, or between application tiers in microservices	At the edge (internet-facing) or as an API gateway in front of services	Architecture matters: edge reverse proxies handle SSL/caching, internal LBs distribute traffic

Overlapping Capabilities

Modern tools blur these boundaries:

• Nginx: Started as a web server/reverse proxy, added load balancing via upstream blocks. In production, often used for both—SSL termination + caching (reverse proxy) AND traffic distribution (load balancer).
• HAProxy: Started as a pure load balancer, added Layer 7 features like request inspection, header manipulation, and basic caching. Now competes with Nginx for reverse proxy use cases.
• Cloud Load Balancers: AWS ALB, Google Cloud Load Balancer offer Layer 7 features (path-based routing, SSL termination) traditionally associated with reverse proxies, but their primary purpose remains traffic distribution.

The key insight: these tools offer both capabilities, but you deploy them with a primary purpose in mind. When Cloudflare deploys Nginx at their edge, the primary purpose is reverse proxy (SSL, caching, DDoS protection). When Uber uses HAProxy between services, the primary purpose is load balancing (traffic distribution, failover).

Load Balancer vs Reverse Proxy: Architectural Comparison

graph LR
    subgraph Load Balancer Architecture
        Client1["Client"] --"1. Request"--> LB["Load Balancer<br/><i>Traffic Distribution</i>"]
        LB --"2a. Route (Round-Robin)"--> App1["App Server 1"]
        LB --"2b. Route (Health Check)"--> App2["App Server 2"]
        LB --"2c. Route (Failover)"--> App3["App Server 3"]
        App1 & App2 & App3 --"3. Query"--> DB1[("Database")]
        App1 & App2 & App3 --"4. Response"--> LB
        LB --"5. Response"--> Client1
    end
    
    subgraph Reverse Proxy Architecture
        Client2["Client"] --"1. HTTPS Request"--> RP["Reverse Proxy<br/><i>Request Handler</i>"]
        RP --"2. Check Cache"--> Cache[("Cache<br/>Redis")]
        RP --"3. SSL Terminated<br/>HTTP Request"--> App4["App Server<br/><i>Single or Multiple</i>"]
        App4 --"4. Response"--> RP
        RP --"5. Cache + Compress"--> Cache
        RP --"6. HTTPS Response"--> Client2
    end

Load balancers focus on distributing traffic across multiple servers with health checks and failover, while reverse proxies focus on request transformation, caching, and SSL termination. Note that reverse proxies add value even with a single backend server, whereas load balancers require multiple servers for meaningful failover.

Deep Analysis

Load Balancer: The Traffic Conductor

Load balancers solve the availability and scalability problem: how do you distribute incoming requests across N servers so that no single server becomes a bottleneck or single point of failure? This is fundamentally a routing problem. The load balancer maintains a pool of healthy backend servers, continuously health-checks them (HTTP probes, TCP connections), and routes each incoming request to an available server using an algorithm (round-robin, least connections, IP hash).

See Load Balancers Overview for load balancer fundamentals and Load Balancing Algorithms for distribution strategies.

The critical capability is failover: when a backend server crashes or becomes unresponsive, the load balancer automatically removes it from the pool and redistributes traffic to healthy servers. This is why load balancers require multiple backend servers—with only one server, there’s nothing to fail over to. Netflix’s Zuul (their edge load balancer) routes requests across thousands of microservice instances, automatically removing unhealthy instances based on error rates and latency metrics. This is load balancing at scale.

Load balancers also handle session persistence (sticky sessions): ensuring that a user’s requests consistently route to the same backend server when the application maintains server-side session state. This is a load balancing concern because it affects routing decisions—the load balancer must track which user maps to which server.

Reverse Proxy: The Request Handler

Reverse proxies solve the request processing problem: how do you handle, transform, and optimize requests before they reach your application servers? This is fundamentally a middleware problem. The reverse proxy sits between clients and servers, intercepting requests to perform operations like SSL termination, caching, compression, authentication, and request/response modification.

The killer feature is caching: a reverse proxy can cache static assets (images, CSS, JavaScript) and even dynamic API responses, serving them directly without hitting backend servers. Cloudflare’s reverse proxy caches content at 300+ edge locations worldwide, reducing origin server load by 60-80% for typical websites. This is reverse proxy value—even if you have a single origin server, the reverse proxy dramatically improves performance and reduces load.

SSL termination is another core use case: the reverse proxy handles TLS encryption/decryption at the edge, forwarding plain HTTP to backend servers. This offloads CPU-intensive cryptographic operations from application servers and centralizes certificate management. Stripe uses Nginx reverse proxies to terminate SSL for API requests, then forwards to internal services over a trusted network.

Reverse proxies also provide security: they hide backend server details (IP addresses, server software), implement rate limiting, filter malicious requests, and provide a single point for authentication/authorization. This is why API gateways (Kong, Apigee) are essentially reverse proxies with enhanced security and routing features.

The Convergence: Why Modern Tools Do Both

The lines blurred because real-world systems need both capabilities. Consider a typical production architecture:

1. Edge Layer: Nginx reverse proxy handles SSL termination, caches static assets, compresses responses, implements rate limiting.
2. Load Balancing Layer: Nginx (or HAProxy) distributes traffic across 10 application servers using least-connections algorithm, health-checks each server every 5 seconds.
3. Application Layer: Stateless application servers process requests.

In this architecture, Nginx appears twice—once as a reverse proxy (edge), once as a load balancer (internal). The same tool, different purposes. This is why the conceptual distinction matters: you’re solving different problems at each layer.

Cloud providers further blur the lines. AWS Application Load Balancer (ALB) offers Layer 7 routing, SSL termination, and path-based routing—traditionally reverse proxy features—but its primary purpose is traffic distribution across EC2 instances or containers. You wouldn’t use ALB for caching (use CloudFront for that), but you would use it for load balancing with some request handling.

Single Point of Failure Consideration

Both load balancers and reverse proxies introduce a potential single point of failure. If your load balancer crashes, all traffic stops. If your reverse proxy fails, clients can’t reach your application. The solution is the same: deploy multiple instances with failover. Cloud load balancers (AWS ELB, GCP Load Balancer) are highly available by design, running across multiple availability zones. For self-hosted Nginx or HAProxy, you’d deploy active-passive pairs with keepalived or use DNS-based failover. This operational complexity is the trade-off for the benefits these components provide.

Modern Tool Convergence: Nginx Dual-Role Deployment

graph TB
    subgraph Edge Layer - Reverse Proxy Role
        Internet["Internet Traffic"] --"HTTPS"--> EdgeNginx["Nginx<br/><i>Reverse Proxy Mode</i>"]
        EdgeNginx --"SSL Termination"--> SSL["TLS/Certificate<br/>Management"]
        EdgeNginx --"Cache Check"--> EdgeCache[("Static Asset Cache")]
        EdgeNginx --"Rate Limiting"--> RateLimit["Rate Limiter<br/>per-IP rules"]
        EdgeNginx --"HTTP (decrypted)"--> InternalNginx
    end
    
    subgraph Internal Layer - Load Balancer Role
        InternalNginx["Nginx<br/><i>Load Balancer Mode</i>"]
        InternalNginx --"Health Check<br/>every 5s"--> Health["Health Monitor"]
        InternalNginx --"1. Least Connections"--> App1["App Server 1"]
        InternalNginx --"2. Round Robin"--> App2["App Server 2"]
        InternalNginx --"3. Failover"--> App3["App Server 3"]
    end
    
    subgraph Application Layer
        App1 & App2 & App3 --"Read/Write"--> AppDB[("PostgreSQL")]
    end

Production systems often use the same tool (Nginx) in both roles: as a reverse proxy at the edge for SSL/caching/security, and as a load balancer internally for traffic distribution. This layered architecture separates concerns—edge layer handles request processing, internal layer handles traffic routing.

Capacity Impact: Reverse Proxy Caching Benefits

graph LR
    subgraph Without Reverse Proxy
        Client1["1000 req/sec"] --"100% traffic"--> App1["App Servers<br/><i>10 servers needed</i><br/>100 req/sec each"]
        App1 --"Database load"--> DB1[("Database<br/><i>1000 queries/sec</i>")]
    end
    
    subgraph With Reverse Proxy - 70% Cache Hit Rate
        Client2["1000 req/sec"] --"100% traffic"--> RP["Reverse Proxy<br/><i>Nginx + Redis</i>"]
        RP --"70% cached<br/>700 req/sec"--> Cache[("Cache<br/><i>Served from memory</i>")]
        RP --"30% miss<br/>300 req/sec"--> App2["App Servers<br/><i>3 servers needed</i><br/>100 req/sec each"]
        App2 --"Reduced load"--> DB2[("Database<br/><i>300 queries/sec</i>")]
        Cache --"Instant response"--> RP
        App2 --"Response + Cache"--> RP
    end
    
    Calculation["💡 Capacity Calculation:<br/>70% cache hit = 3.3x capacity<br/>Same 10 servers handle 3,300 req/sec<br/>OR handle 1,000 req/sec with 3 servers"]

Senior-level insight: A reverse proxy with 70% cache hit rate reduces backend load by 70%, allowing you to handle 3.3x more traffic with the same infrastructure or reduce server count by 70%. This calculation is critical for capacity planning and cost optimization discussions in interviews.

Decision Framework

When to Use a Load Balancer

Choose a dedicated load balancer when:

1. You have 2+ backend servers and need traffic distribution with automatic failover. This is the core load balancing use case.
2. High availability is critical: You need sophisticated health checking, automatic removal of failed servers, and seamless failover without dropped requests.
3. You need session persistence: Your application maintains server-side session state and requires sticky sessions.
4. Layer 4 load balancing is sufficient: You’re distributing TCP/UDP traffic (databases, message queues) and don’t need Layer 7 inspection. See Layer 4 Load Balancing for transport-layer details.
5. You’re scaling horizontally: Adding more application servers to handle increased load. See Horizontal Scaling for scaling strategies.

Example: Uber’s microservices architecture uses HAProxy to distribute traffic across hundreds of service instances, with health checks every 2 seconds and automatic failover when instances crash.

When to Use a Reverse Proxy

Choose a reverse proxy when:

1. You have a single backend server but need SSL termination, caching, or security features. Reverse proxies add value even without multiple servers.
2. Caching is a priority: You want to cache static assets or API responses at the edge to reduce backend load and improve latency.
3. SSL termination is required: You need to decrypt HTTPS at the edge and forward plain HTTP internally, centralizing certificate management.
4. Request/response transformation: You need to rewrite URLs, modify headers, compress responses, or implement authentication before requests reach your application.
5. Security and rate limiting: You want a single point to filter malicious requests, implement rate limiting, or hide backend server details.

Example: A startup with a single Django application server deploys Nginx as a reverse proxy to handle SSL, cache static assets, and compress responses—improving performance without adding application servers.

When to Use Both (Combined Architecture)

Most production systems use both in a layered architecture:

1. Edge Reverse Proxy: Handles SSL termination, caches static content, implements rate limiting, provides DDoS protection.
2. Internal Load Balancer: Distributes traffic across application servers, performs health checks, handles failover.

This separation of concerns is optimal:

• Edge layer focuses on request handling and optimization (reverse proxy concerns).
• Internal layer focuses on traffic distribution and availability (load balancing concerns).

Example: Cloudflare’s architecture uses Nginx reverse proxies at 300+ edge locations for SSL/caching, then routes dynamic requests through internal load balancers to origin servers.

Decision Tree

Start here: Do you have multiple backend servers?

• No (single server): Use a reverse proxy (Nginx, Varnish) for SSL, caching, and security. You’ll add load balancing later when you scale horizontally.
• Yes (2+ servers): Do you need caching or extensive request transformation?
  • Yes: Use both—reverse proxy at the edge, load balancer internally.
  • No: Use a load balancer (HAProxy, cloud LB) for traffic distribution and failover.

Cloud vs. Self-Hosted:

• Cloud: Use managed load balancers (AWS ALB, GCP Load Balancer) for traffic distribution. Add CloudFront or Cloudflare for reverse proxy features (caching, SSL).
• Self-Hosted: Deploy Nginx or HAProxy in both roles—configure one instance as a reverse proxy (edge), another as a load balancer (internal).

Common Anti-Patterns

1. Using a load balancer with a single server: Adds complexity without failover benefits. Use a reverse proxy instead.
2. Skipping the edge reverse proxy: Forcing application servers to handle SSL termination and serve static assets wastes resources.
3. Conflating the two: Saying “I’ll use Nginx” without specifying whether you need its reverse proxy features, load balancing capabilities, or both.
4. Over-engineering: A small application doesn’t need both—start with a reverse proxy, add load balancing when you scale to multiple servers.

Decision Tree: Choosing Load Balancer, Reverse Proxy, or Both

flowchart TB
    Start["Start: Infrastructure Design"] --> Q1{"Do you have<br/>2+ backend servers?"}
    
    Q1 --"No (Single Server)"--> Q2{"Need SSL termination,<br/>caching, or security?"}
    Q2 --"Yes"--> RP["✓ Deploy Reverse Proxy<br/><i>Nginx, Varnish</i><br/>SSL + Cache + Security"]
    Q2 --"No"--> Simple["Direct Connection<br/><i>Add reverse proxy later</i>"]
    
    Q1 --"Yes (Multiple Servers)"--> Q3{"Need caching or<br/>request transformation?"}
    
    Q3 --"No"--> LB["✓ Deploy Load Balancer<br/><i>HAProxy, Cloud LB</i><br/>Traffic Distribution + Failover"]
    
    Q3 --"Yes"--> Q4{"Cloud or<br/>Self-Hosted?"}
    
    Q4 --"Cloud"--> CloudArch["✓ Layered Cloud Architecture<br/>CloudFront/Cloudflare (RP)<br/>+ AWS ALB/GCP LB (LB)"]
    
    Q4 --"Self-Hosted"--> SelfArch["✓ Layered Self-Hosted<br/>Edge Nginx (RP)<br/>+ Internal HAProxy/Nginx (LB)"]
    
    RP --> Scale{"Planning to scale<br/>to multiple servers?"}
    Scale --"Yes"--> AddLB["Add Load Balancer<br/>when scaling horizontally"]
    Scale --"No"--> End1["Single-tier architecture<br/>sufficient for now"]
    
    LB --> Future{"Future caching<br/>or SSL needs?"}
    Future --"Yes"--> AddRP["Add Reverse Proxy<br/>at edge layer"]
    Future --"No"--> End2["Pure load balancing<br/>architecture"]
    
    CloudArch --> End3["Production-ready<br/>architecture"]
    SelfArch --> End3

Decision framework for choosing between load balancer, reverse proxy, or both. The key decision point is whether you have multiple servers (load balancing) and whether you need request processing features (reverse proxy). Most production systems end up with both in a layered architecture.

Real-World Examples

Cloudflare: Reverse Proxy at Global Scale

System: Cloudflare’s edge network

Implementation: Cloudflare operates 300+ data centers worldwide, each running Nginx reverse proxies that terminate SSL, cache content, filter DDoS attacks, and optimize requests before forwarding to origin servers. When you add a website to Cloudflare, you’re placing a reverse proxy between your users and your origin server.

Interesting Detail: Cloudflare’s reverse proxies cache 60-80% of requests for typical websites, meaning only 20-40% of traffic reaches origin servers. This is pure reverse proxy value—even if the origin is a single server, Cloudflare’s caching dramatically reduces load. They also use Nginx’s request transformation capabilities to implement features like automatic HTTPS rewrites, minification, and image optimization. The origin servers don’t need to scale because the reverse proxy layer absorbs most traffic.

Interview Insight: This example demonstrates reverse proxy value without load balancing—Cloudflare doesn’t care if your origin is one server or ten. The reverse proxy solves caching, SSL, and security problems independently of backend scaling.

Netflix: Load Balancing Across Microservices

System: Zuul, Netflix’s edge load balancer

Implementation: Netflix’s Zuul routes incoming API requests across thousands of microservice instances running in AWS. Each microservice (user profiles, recommendations, video metadata) runs 10-100+ instances, and Zuul distributes traffic using dynamic routing rules based on service health, latency, and error rates. When a microservice instance crashes or becomes slow, Zuul automatically removes it from the routing pool.

Interesting Detail: Zuul implements sophisticated health checking—it doesn’t just ping instances, it tracks error rates and latency percentiles (P99, P99.9) and removes instances that degrade performance even if they’re technically “up.” This is advanced load balancing: routing decisions based on real-time performance metrics, not just binary health checks. Netflix also uses Zuul for some reverse proxy features (request filtering, authentication), but its primary purpose is load balancing across a massive microservices architecture.

Interview Insight: This example shows load balancing at scale—Zuul’s value comes from distributing traffic across thousands of instances with intelligent failover. The reverse proxy features (filtering, auth) are secondary to the core load balancing mission.

Stripe: Layered Architecture (Both)

System: Stripe’s API infrastructure

Implementation: Stripe uses a layered approach: Nginx reverse proxies at the edge terminate SSL and implement rate limiting, then forward requests to HAProxy load balancers that distribute traffic across API server clusters. The edge Nginx layer handles 100% of SSL termination (reducing CPU load on API servers) and implements per-customer rate limits (preventing abuse). The internal HAProxy layer distributes traffic across API servers using least-connections algorithm, with health checks every 5 seconds.

Interesting Detail: Stripe’s architecture separates concerns—the edge layer (reverse proxy) focuses on security and request handling, the internal layer (load balancer) focuses on traffic distribution and failover. This separation allows them to optimize each layer independently: the edge layer uses Nginx’s SSL performance and rate limiting capabilities, the internal layer uses HAProxy’s sophisticated load balancing algorithms and health checking. They could swap out either layer without affecting the other.

Interview Insight: This is the canonical production architecture—reverse proxy at the edge, load balancer internally. In interviews, describing this layered approach demonstrates understanding of separation of concerns and real-world infrastructure patterns.

Stripe’s Layered Architecture: Separation of Concerns

graph TB
    subgraph Internet
        Clients["API Clients<br/><i>Millions of requests/sec</i>"]
    end
    
    subgraph Edge Layer - Reverse Proxy
        Clients --"HTTPS"--> EdgeNginx1["Nginx RP 1<br/><i>us-east-1a</i>"]
        Clients --"HTTPS"--> EdgeNginx2["Nginx RP 2<br/><i>us-east-1b</i>"]
        EdgeNginx1 & EdgeNginx2 --"SSL Termination"--> SSL["Certificate<br/>Management"]
        EdgeNginx1 & EdgeNginx2 --"Rate Limiting"--> RateLimit["Per-Customer<br/>Rate Limits"]
        EdgeNginx1 & EdgeNginx2 --"HTTP (decrypted)"--> HAProxy1
        EdgeNginx1 & EdgeNginx2 --"HTTP (decrypted)"--> HAProxy2
    end
    
    subgraph Load Balancing Layer
        HAProxy1["HAProxy LB 1<br/><i>Least Connections</i>"]
        HAProxy2["HAProxy LB 2<br/><i>Active-Passive</i>"]
        HAProxy1 & HAProxy2 --"Health Check<br/>every 5s"--> HealthCheck["Health Monitor<br/>TCP + HTTP probes"]
    end
    
    subgraph API Server Cluster
        HAProxy1 --"1. Route"--> API1["API Server 1"]
        HAProxy1 --"2. Route"--> API2["API Server 2"]
        HAProxy1 --"3. Route"--> API3["API Server 3"]
        HAProxy2 --"Failover"--> API1 & API2 & API3
        API1 & API2 & API3 --"Query"--> DB[("PostgreSQL<br/>Primary + Replicas")]
    end
    
    EdgeNginx1 -."Failover".-> EdgeNginx2
    HAProxy1 -."Keepalived VIP".-> HAProxy2

Stripe’s production architecture demonstrates separation of concerns: Nginx reverse proxies at the edge handle SSL termination and rate limiting (reducing CPU load and preventing abuse), while HAProxy load balancers internally distribute traffic across API servers with sophisticated health checking. Each layer is redundant for high availability.

---

Interview Essentials

Mid-Level

Clearly articulate the primary purpose of each: load balancers distribute traffic across multiple servers for availability/scalability, reverse proxies handle request processing (SSL, caching, security) and add value even with a single server.

Explain that modern tools (Nginx, HAProxy) offer both capabilities, but you deploy them with a primary purpose in mind based on the problem you’re solving.

Describe a basic architecture: reverse proxy at the edge for SSL/caching, load balancer internally for traffic distribution across application servers.

Understand that load balancers require 2+ backend servers to be meaningful (for failover), while reverse proxies are useful even with a single backend server.

Senior

Justify architectural decisions: explain when you’d use a pure load balancer (Layer 4 traffic distribution), pure reverse proxy (single server with caching needs), or both (layered architecture for separation of concerns).

Discuss trade-offs: reverse proxies add latency (request processing overhead) but reduce backend load (caching); load balancers add complexity (health checking, session persistence) but provide high availability.

Explain how cloud load balancers (AWS ALB, GCP Load Balancer) blur the lines by offering Layer 7 features (SSL termination, path-based routing) traditionally associated with reverse proxies.

Describe failure scenarios: what happens if the reverse proxy crashes? (clients can’t reach the application—need redundancy). What happens if a backend server crashes? (load balancer removes it from the pool—automatic failover).

Calculate capacity: if your reverse proxy caches 70% of requests, how does that affect backend server requirements? (you can handle 3x more traffic with the same number of application servers).

Staff+

Design a global edge architecture: explain how you’d deploy reverse proxies at multiple geographic locations (CDN-style) for caching and SSL termination, then route dynamic requests through regional load balancers to application clusters.

Discuss advanced health checking: beyond binary up/down checks, how do you implement latency-based routing (remove slow instances) or error-rate-based routing (remove instances with high 5xx rates)?

Explain session persistence trade-offs: sticky sessions simplify application logic but create uneven load distribution and complicate failover. How do you migrate to stateless applications with external session storage (Redis, DynamoDB)?

Justify tool selection: when would you choose HAProxy over Nginx? (HAProxy excels at pure load balancing with sophisticated algorithms; Nginx excels at reverse proxy features like caching and SSL). When would you use cloud-managed load balancers vs. self-hosted? (managed LBs reduce operational burden but offer less control).

Design for failure: how do you make the load balancer/reverse proxy layer itself highly available? (active-passive pairs with keepalived, DNS-based failover, cloud-managed LBs with multi-AZ deployment). What’s the blast radius if the edge reverse proxy layer fails? (entire application becomes unreachable—this is why Cloudflare runs redundant edge infrastructure).

Common Interview Questions

Q: Can a reverse proxy do load balancing? A: Yes, modern reverse proxies (Nginx, HAProxy) can distribute traffic across multiple backends. The distinction is conceptual—when you deploy Nginx primarily for traffic distribution, you’re using it as a load balancer. When you deploy it primarily for SSL/caching, you’re using it as a reverse proxy. The same tool, different purposes.

Q: Do I need both a load balancer and a reverse proxy? A: It depends on your requirements. If you have a single server, start with a reverse proxy for SSL/caching. When you scale to multiple servers, add load balancing (either by configuring your reverse proxy to distribute traffic or adding a dedicated load balancer). Most production systems use both in a layered architecture.

Q: What’s the difference between a reverse proxy and a forward proxy? A: See Forward Proxy for client-side proxy concepts. Briefly: forward proxies sit on the client side (hiding client identity, filtering outbound requests), reverse proxies sit on the server side (hiding server identity, handling inbound requests).

Q: Can I use a cloud load balancer (AWS ALB) as a reverse proxy? A: Partially. Cloud load balancers offer some reverse proxy features (SSL termination, path-based routing, header modification), but they don’t cache content or provide the full request transformation capabilities of dedicated reverse proxies. For caching, you’d use a CDN (CloudFront, Cloudflare) in front of the load balancer.

Q: How do I make my load balancer/reverse proxy highly available? A: Deploy multiple instances with failover. Cloud-managed load balancers (AWS ELB, GCP Load Balancer) are highly available by design. For self-hosted solutions, use active-passive pairs with keepalived (virtual IP failover) or DNS-based failover. The reverse proxy/load balancer layer itself becomes a distributed system.

Red Flags to Avoid

Saying ‘they’re the same thing’ without acknowledging the conceptual distinction between traffic distribution (load balancing) and request handling (reverse proxy).

Claiming you need a load balancer for a single-server application—this shows you don’t understand that load balancers require multiple backends for failover.

Not mentioning caching as a key reverse proxy capability—caching is often the primary reason to deploy a reverse proxy.

Ignoring the single point of failure problem—both load balancers and reverse proxies need redundancy for high availability.

Conflating Layer 4 and Layer 7 load balancing—Layer 4 LBs are pure traffic routers (no request inspection), Layer 7 LBs and reverse proxies both inspect application data.

Not discussing separation of concerns in a layered architecture—edge reverse proxy for SSL/caching, internal load balancer for traffic distribution.

---

Key Takeaways

Core Distinction: Load balancers distribute traffic across multiple servers for availability and scalability (solving the ‘where does this request go?’ problem). Reverse proxies handle and transform requests for caching, SSL termination, and security (solving the ‘how should I process this request?’ problem). Modern tools do both, but you deploy them with a primary purpose in mind.

Single Server Test: Reverse proxies add value even with a single backend server (SSL offloading, caching, security). Load balancers require 2+ servers to be meaningful—with one server, there’s nothing to fail over to. This is the clearest way to distinguish them.

Layered Architecture: Production systems typically use both—a reverse proxy at the edge (SSL termination, caching, rate limiting) and a load balancer internally (traffic distribution, health checking, failover). This separation of concerns allows each layer to focus on its core responsibility.

Tool Convergence: Nginx and HAProxy offer both load balancing and reverse proxy capabilities. The distinction is conceptual, not technical—you configure the same tool differently based on whether you need traffic distribution (load balancing) or request handling (reverse proxy). Cloud load balancers (AWS ALB) blur the lines further by offering Layer 7 features traditionally associated with reverse proxies.

High Availability: Both load balancers and reverse proxies are potential single points of failure. Deploy multiple instances with failover (active-passive pairs, DNS-based failover, or cloud-managed solutions with multi-AZ deployment) to ensure the infrastructure layer itself is highly available.

---