A load balancer is a traffic controller that sits in front of a group of servers. Visitors connect to the load balancer, and it passes each request to one of the servers behind it, so the work is shared and a single broken machine does not take the whole site down.
How a load balancer chooses a server
The balancer keeps a list of backend servers, often called a pool. For each new request it picks one using a rule. Round robin goes through the list in turn. Least connections picks the server with the fewest open connections. Hash-based methods send the same visitor to the same server each time. Meanwhile it runs health checks, regularly requesting a test page from every server, and removes any that stop answering until they recover.
A layer 4 balancer works at the connection level, looking only at IP addresses and ports. A layer 7 balancer understands HTTP, so it can route by URL path or hostname, for instance sending /api to one group of servers and everything else to another.
Where load balancers come from
Cloud providers sell them as managed services, such as AWS Elastic Load Balancing, Google Cloud Load Balancing and Azure Load Balancer. Software options include Nginx and HAProxy. Platform hosts and CDNs also do this internally without you configuring anything.
Example: a ticket sale
A local theatre opens online booking for a popular show. Its booking app runs on three identical servers behind a load balancer. When the rush starts, requests are shared out so none of the servers is swamped. Midway through, one server runs out of memory and stops responding; the health check notices and traffic shifts to the other two. Customers may see some slowness, but the box office stays open.
Does a small business need one?
Usually not directly. A typical small-business site runs comfortably on one server or a managed platform that balances load for you behind the scenes. You start needing your own when a single server cannot handle peak traffic, or when the business cannot afford downtime while one machine is patched or replaced.
Load-balancing mistakes
- Storing logins or carts in one server's memory. The next request can land on a different server where that session does not exist. Keep sessions in a shared store or a cookie.
- A health check that always passes. Checking a static file says nothing about whether the database connection works.
- One load balancer with no backup. It becomes the new single point of failure. Managed cloud balancers handle this for you.
- Losing visitor IPs. Apps behind a balancer must read the forwarded header to see who is really connecting.