A load balancer is the traffic director that sits in front of a group of servers and spreads incoming requests across them. Instead of every visitor hitting the same machine, the load balancer hands each request to whichever server has capacity, so none of them gets overwhelmed while others sit idle. It is the piece that makes load balancing actually happen.
Picture the staff at a supermarket who direct shoppers to whichever checkout has the shortest queue. Nobody waits behind a jammed register while another stands empty, and the whole store flows faster. A load balancer does this for web requests, and it does something a supermarket cannot: if a checkout closes unexpectedly, it instantly reroutes everyone to the open ones. That is why it often works hand in hand with auto-scaling, adding servers behind it as traffic climbs.
Load balancers also do health checks. They quietly probe each server, and the moment one stops responding, they pull it out of rotation so visitors are never sent to a broken machine.
There is one detail worth planning for. If a user’s session lives only on one server, you either need sticky sessions, which pin that user to the same machine, or you store session data somewhere shared so any server can pick up the request. Most teams choose the shared option, because sticky sessions can leave one machine crowded while others sit idle. Many also pair the load balancer with a reverse proxy like Nginx, which handles TLS and caching at the same front door.
At TopDevs we put a load balancer in front of high-traffic client systems so the site stays fast during busy spikes and keeps running even when a single server fails.
