A load balancer sits between clients and a group of backend servers, forwarding each request to one of those servers based on a chosen algorithm. This spreads the workload evenly, prevents any single server from becoming a bottleneck, and keeps your service running even if one server fails.
Load balancers work at different layers. Layer 4 (transport) balancers route based on IP protocol data, while Layer 7 (application) balancers can inspect HTTP headers and direct traffic based on URL paths, hostnames, or other application-level details.
Common balancing algorithms:
- Round robin: distributes requests equally in order
- Least connections: sends traffic to the server handling fewest active connections
- IP hash: routes based on client IP for session persistence
- Weighted: assigns more traffic to more powerful servers
Load balancers also perform health checks—periodically testing backend servers and removing unresponsive ones from the rotation. This ensures traffic never reaches failed or degraded servers.
Example setup: Two web servers behind a load balancer at example.com. Your A record points to the load balancer's IP. When a user visits example.com, the load balancer routes their request to either server 1 or server 2 (or splits sessions across both). If server 1 goes down, all traffic automatically routes to server 2, maintaining uptime.
TipLoad balancers are essential for high-availability architectures. Pair them with DNS and status pages to provide redundancy and visibility.
Cloud providers offer managed load balancers as a service; on-premises deployments often use dedicated hardware or software like NGINX or HAProxy.