Load balancer: what it does and how to choose an algorithm
A load balancer sits in front of your servers and shares traffic between them. Learn L4 vs L7, the main algorithms and how health checks keep users away from dead servers.
A load balancer receives incoming requests and forwards each one to one of several backend servers. It gives you more capacity, and it hides a failed server from users.
Layer 4 vs Layer 7
- L4 (transport): decides using IP and port only. Very fast and simple, but it cannot look inside the request.
- L7 (application): reads the HTTP request, so it can route by path (
/apivs/images), host or header, terminate TLS and add caching. Nginx, HAProxy, Envoy and cloud application load balancers work here.
Common algorithms
- Round robin: servers take turns. Fine when requests cost about the same.
- Weighted round robin: bigger servers get more.
- Least connections: send to the server with the fewest active requests. Good when requests vary in length.
- IP hash / consistent hash: the same client goes to the same server. Useful for caches and sticky behaviour.
Health checks
The balancer pings each server (for example GET /health) and removes any that fail, then adds them back when they recover. Without this, users hit dead servers.
Sticky sessions
Sending a user to the same server keeps in-memory sessions working, but it unbalances load and breaks when that server dies. Prefer stateless servers with sessions in Redis or a token.
The balancer itself
One load balancer is a single point of failure. Run two (active/passive or active/active) behind a shared IP or DNS, or use a managed one from your cloud.
Takeaway: use L7 for web apps, start with round robin or least connections, always configure health checks, and never leave a single balancer alone.
Part 4 of 15 in the System Design series. Previous: CAP theorem in plain words, with examples.
