Load balancers explained: Layer 4 vs Layer 7 and health checks

A load balancer sits in front of several servers and spreads incoming requests across them. It gives you more capacity, better availability (if one server dies, traffic goes to the others) and the freedom to update servers one at a time.

Layer 4 vs Layer 7

The numbers refer to layers of the network model.

Layer 4 (transport): decides using IP addresses and ports (TCP or UDP). It does not look inside the traffic.

• Very fast and simple.
• Works for any TCP or UDP protocol (databases, game servers, mail).
• Cannot route by URL or header.

Layer 7 (application): understands HTTP.

• Routes by host name, path, headers or cookies (for example /api goes to one group, /images to another).
• Can terminate TLS, compress, cache, rewrite and redirect.
• Can apply rate limits or a web application firewall.
• Uses a bit more CPU than layer 4.

Many cloud providers offer both, such as network and application load balancers.

Balancing algorithms

• Round robin: each server in turn. Simple, fine for similar servers and requests.
• Weighted round robin: stronger servers get more traffic.
• Least connections: the server with the fewest active connections. Good when requests take uneven time.
• IP hash: the same client IP goes to the same server.
• Consistent hashing: maps a key (such as a user or cache key) to a server while limiting reshuffling when servers change.

Health checks

The balancer regularly checks each server and stops sending traffic to unhealthy ones.

• A TCP check only tests that the port accepts connections.
• An HTTP check requests a path such as /health and expects a 200.
• Make the health endpoint meaningful but cheap. It should show the app can really serve (for example it can reach its database), without being so heavy that it causes load.
• Tune the interval and the number of failures so brief blips do not remove servers and real failures are caught quickly.

Use connection draining so that a server being removed finishes its current requests first.

Sessions and stickiness

If a server keeps user session data in its own memory, a user sent to a different server loses it. Options:

• Sticky sessions (affinity): the balancer keeps sending a user to the same server, using a cookie or IP. Easy, but uneven load and trouble when that server dies.
• Better: keep the application stateless and store sessions in a shared store such as Redis or a database, or use signed tokens. Then any server can handle any request.

TLS termination

A Layer 7 balancer can terminate TLS: it holds the certificate, decrypts traffic and forwards it to the servers, so the servers do less crypto work and certificates are managed in one place. For sensitive data, re-encrypt traffic between the balancer and the servers too.

Pass the real client IP using headers such as X-Forwarded-For and trust those headers only from your own balancer.

Do not create a new single point of failure

One load balancer is itself a risk. Cloud load balancers are built redundant across zones. If you run your own (Nginx, HAProxy), use two or more with a floating IP or DNS failover, and spread servers over several availability zones.

Other forms

• DNS load balancing: returns several IPs. Simple, but cached answers react slowly to failures.
• Global load balancing and CDNs: send users to the nearest healthy region.
• Client-side balancing and service meshes: services choose a backend themselves.

Quick Nginx example

upstream app {
    least_conn;
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
    server 10.0.1.13:3000 backup;
}
server {
    location / { proxy_pass http://app; }
}

Takeaway: a load balancer adds capacity and resilience. Use Layer 4 for speed and any protocol, Layer 7 for smart HTTP routing, check health honestly, keep servers stateless and make sure the balancer itself is redundant.

---

Networking & Cloud series, Part 1 (how the internet works): 4 of 5. Previous: HTTP, HTTPS and TLS: what happens when you open a website.