A reverse proxy sits in front of your backend and acts on behalf of the server. Clients never talk directly to your origin.

In the diagram, the client sends HTTPS, but the proxy forwards plain HTTP internally. That's SSL termination - the proxy handles encryption so your app doesn't have to.

Examples: Nginx, Caddy, HAProxy, Cloudflare. Even a CDN is essentially a globally distributed reverse proxy.

An API Gateway is a specialized reverse proxy built for APIs. It adds application-aware features on top of basic proxying.

Notice how requests to /users, /orders, and /pay each route to different backend services.

Examples: Kong, AWS API Gateway, Apigee. This is the front door to your microservices - it keeps cross-cutting concerns out of business logic.

Now the Load Balancer. While a reverse proxy can sit in front of one server, a load balancer distributes traffic across multiple servers. It's how you scale horizontally.

The simplest strategy is Round Robin: requests cycle through servers in order - 1 → 2 → 3 → 1 → 2 → 3.

Weighted Round Robin is a variant where beefier servers get a larger share. A server with weight 3 gets three requests for every one sent to a weight-1 server.

Smarter than round robin. The load balancer tracks active connections per server and routes new requests to the one with the fewest.

The badges show this clearly - App #2 has only 3 active connections vs 12 and 7, so every new request goes there.

This is what most production setups use when connections have varying durations. AWS ALB uses a variant of this by default.

The load balancer periodically pings each server with a health check - typically GET /health every 10-30 seconds.

In the diagram, App #2 fails its health check, turns red, and gets pulled from rotation. Traffic automatically reroutes to the remaining healthy servers.

This is how systems stay available during deployments, crashes, or scaling events, with no manual intervention needed.

Sometimes you need the same user to hit the same server, usually because session state is stored in server memory.

Here, User A (blue) always goes to App #1, and User B (green) always goes to App #2. The LB uses a cookie or IP hash to maintain that affinity.

Use sticky sessions as a temporary solution or when migrating from a stateful app. The goal should always be stateless servers behind the LB.

This is the most important distinction in load balancing.

In the diagram, the L7 LB reads the request path and routes /images to App #1, /api to App #2, and /static to App #3. Each path lands on its own dedicated service.

L7 is what you want for microservices, API gateways, and anything where routing depends on the content of the request.

These three components often overlap, and in production you typically layer them:

• →Reverse Proxy (Nginx/Cloudflare) handles SSL, caching, compression at the edge
• →API Gateway (Kong/AWS) handles auth, rate limiting, and routes to services
• →Load Balancer (ALB/NLB) distributes traffic within each service cluster
• →Health checks automatically pull unhealthy instances from rotation

Knowing the distinction between these layers, and when each one is needed, is the foundation of designing resilient, scalable backend infrastructure.