Stop Confusing API Gateway, Load Balancer, and Reverse Proxy

If you've ever been in a system design interview or an architecture review and heard someone say "just put a load balancer in front of it" when they actually meant an API Gateway - you're not alone. These three components sit in similar places in a request's journey, and they even share some overlapping capabilities. That overlap is exactly why people mix them up.

This post breaks down what each one actually does, where it sits in your architecture, and - most importantly - when to use which.

The Core Problem: They All "Sit in Front" of Something

At a glance, all three:

• Receive incoming traffic

• Sit between the client and your backend services

• Can do TLS termination

• Can route requests somewhere

Because of this surface-level similarity, engineers often treat them as interchangeable. They're not. Each was built to solve a different problem, and understanding why each one exists is the key to telling them apart.

Reverse Proxy: The Traffic Doorman

A reverse proxy sits in front of one or more backend servers and forwards client requests to them. The client only ever talks to the proxy - it has no idea what's happening behind it.

Primary job: Hide backend infrastructure, forward requests, and optionally cache or compress responses.

Typical responsibilities:

• TLS termination (decrypting HTTPS so backend servers don't have to)

• Basic request routing (e.g., /images → image server, /api → app server)

• Caching static content

• Compression (gzip/brotli)

• Hiding internal server details and IP addresses

• Basic protection (rate limiting, blocking bad IPs)

Common tools: Nginx, HAProxy (in proxy mode), Apache HTTP Server, Envoy

Mental model: Think of a hotel concierge. Guests (clients) never directly call a specific room — they talk to the concierge, who quietly figures out where to send the request.

Load Balancer: The Traffic Distributor

A load balancer is a specialized type of reverse proxy whose main job is distributing incoming traffic across multiple identical backend instances to prevent any single server from being overwhelmed.

Primary job: Even out traffic across a pool of servers for scalability and fault tolerance.

Typical responsibilities:

• Distributing requests using algorithms like round-robin, least connections, or weighted routing

• Health checks — detecting and routing around unhealthy instances

• Failover when a server goes down

• Operating at Layer 4 (TCP/UDP) or Layer 7 (HTTP)

Common tools: AWS ELB/ALB/NLB, Nginx, HAProxy, Google Cloud Load Balancer, F5

Mental model: Think of an airport check-in area with multiple counters and a staff member directing you: "Counter 4 is free, go there." The staff member doesn't care what's in your request - they just care that no single counter gets overloaded.

Key distinction from Reverse Proxy: Every load balancer is technically a reverse proxy, but not every reverse proxy is a load balancer. A reverse proxy might forward all traffic to a single server; a load balancer's entire purpose is spreading traffic across many.

API Gateway: The Traffic Manager with Business Logic

An API Gateway is a reverse proxy on steroids, purpose-built for managing APIs - particularly in microservices architectures. It doesn't just forward requests; it understands and acts on the content of the API request itself.

Primary job: Be the single entry point for clients to interact with potentially dozens of backend microservices, while handling cross-cutting API concerns.

Typical responsibilities:

• Authentication and authorization (validating API keys, JWTs, OAuth tokens)

• Rate limiting and throttling per client/API key

• Request/response transformation (e.g., XML to JSON)

• Routing requests to the correct microservice based on path, headers, or version

• API versioning

• Aggregating responses from multiple services into one

• Analytics, logging, and monitoring of API usage

• Sometimes load balancing too - as an added feature

Common tools: Kong, AWS API Gateway, Apigee, Zuul, Amazon Kong, Tyk, Traefik (partially)

Mental model: Think of a corporate receptionist who doesn't just point you to a room - they check your ID, verify you have an appointment, log your visit, decide which department actually handles your request, and sometimes even collect information from three departments before giving you a single combined answer.

Side-by-Side Comparison

Where They Actually Overlap (Why the Confusion Exists)

• A load balancer is a reverse proxy - just with a narrower, traffic-distribution-focused purpose.

• An API Gateway often includes reverse proxy and load balancing capabilities.

• Tools like Nginx, Envoy, and Traefik can be configured to act as any of the three, which blurs the lines in practice.

This is the real source of confusion: it's not that these are unrelated concepts, it's that modern tools are flexible enough to wear multiple hats. The distinction lives in intent and primary responsibility, not necessarily in the tool itself.

A Simplified Way to Remember It

• Reverse Proxy → "I forward your request somewhere and hide what's back there."

• Load Balancer → "I make sure no single server gets crushed by traffic."

• API Gateway → "I understand your API request, check who you are, and decide what happens to it."

A Real-World Architecture Example

Imagine a typical microservices-based e-commerce app:

1. Client sends a request to api.mystore.com/orders

2. API Gateway authenticates the request, checks rate limits, and routes it to the orders microservice

3. Behind the gateway, a Load Balancer distributes that request across 5 instances of the orders service running for redundancy

4. Each instance might sit behind a Reverse Proxy (like Nginx) that terminates TLS and forwards to the actual application process

All three components can coexist in the same request path, each solving a different problem at a different layer.

Final Takeaway

These three aren't competing technologies - they're complementary layers that often work together. The confusion comes from overlapping capabilities in modern tools, not from the concepts themselves being similar. Once you anchor on primary intent - hiding backend, distributing load, or managing API policy - the fog clears fast.

Next time someone says "just load balance it" when they mean "add an API gateway," you'll know exactly why that matters.