A load balancer distributes incoming connections or requests across a pool of backend servers. It works at layer 4 (TCP/UDP, by address and port) or layer 7 (HTTP, by host, path or header) and removes unhealthy servers from rotation.
Why it matters
A single server is a single point of failure. With a load balancer you can add capacity, deploy by draining one node at a time and survive a server crash without downtime. The load balancer itself must then be redundant, or it becomes the new single point of failure.
Example
Common algorithms:
- Round robin: each server in turn. Simple, ignores load.
- Least connections: picks the server with the fewest active connections. Better for long requests.
- IP hash / cookie affinity: keeps a client on the same server ("sticky sessions").
An HAProxy backend with health checks:
backend web
balance leastconn
option httpchk GET /healthz
server app1 10.0.0.11:8080 check inter 5s fall 3 rise 2
server app2 10.0.0.12:8080 check inter 5s fall 3 rise 2
Three failed checks (fall 3) remove a server; two passes (rise 2) restore it.
Common mistakes
- Health checks that test only the port, so a server with a broken database stays in rotation.
- Relying on sticky sessions instead of shared session storage, which loses sessions when a node dies.
- Not testing failover, so capacity after losing one node is insufficient.
- Monitoring only the load balancer address, which hides a single unhealthy backend.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.