A traffic jam becomes a routing problem
A website request is a small job: fetch a page, submit a form, or retrieve an image. A load balancer stands in front of a group of servers and chooses which one should handle each job. That choice matters because a server can become overwhelmed even while its neighbors have spare capacity.
The simplest approach is to rotate requests among servers. More sophisticated balancers consider which server has fewer active connections or whether a request belongs to a particular server. The goal is not always to make the distribution perfectly equal; it is to keep work moving without asking one machine to do more than it can handle.
The check is a signal, not a repair
To judge whether a server is available, the balancer periodically sends it a health check—a small test asking whether it can respond. If the server fails enough checks, the balancer stops directing new requests to it. It can be added back after it responds successfully again.
These checks help contain a failure, but they do not fix its cause. A server might be down because of a hardware problem, a software crash, or a dependency such as a database that is itself unavailable. In that last case, sending traffic to more web servers may not restore the site; they may all be waiting on the same broken service.
Nor can routing create capacity from nothing. If every server is busy, requests can still slow down or fail. The practical benefit is narrower and valuable: a single failed server need not become the visitor’s failure too, provided the remaining servers can handle the work.
