A load balancer distributes incoming traffic across several servers. It is often described as a way to make a site faster, which is misleading — one server behind a load balancer is not quicker than the same server without one.
What it actually provides is the ability to have more than one server, and to lose one without anybody noticing.
The three reasons that justify one
You have outgrown one machine. When a single server cannot handle peak traffic even at a reasonable size, distributing requests across several is the way forward. This is horizontal scaling, and a load balancer is what makes it possible.
You cannot afford a single point of failure. One server means every reboot, kernel update and hardware fault is downtime. With health checks, a load balancer stops sending traffic to a server that fails its check and resumes when it recovers — which turns maintenance into a routine operation rather than an outage.
You want deployments without downtime. With two or more servers you can take one out of rotation, update it, verify it, and return it before touching the next. Users never see a restart.
What it demands in return
Multiple servers only work if a request can be served by any of them. That constraint is the real work, and it is where retrofits get expensive.
Sessions must not live in a server's local memory, or a user will be logged out whenever they reach a different one. Uploaded files must not live on a server's local disk, or half your files will be missing half the time. Scheduled jobs must run on exactly one server, not on all of them simultaneously.
The usual answers are a shared session store, object storage or a shared volume for uploads, and either a designated server for cron or a locking mechanism. Sticky sessions can paper over the first problem by pinning a user to one server, but they reintroduce the failure they were meant to remove — that user's session dies with that server.
TLS termination, which is often the real motive
A load balancer can decrypt HTTPS at the edge and forward plain HTTP to the backends. Certificates then live in one place instead of on every server, and renewal happens once.
For a fleet of any size, this simplification alone frequently justifies the component — regardless of how much traffic there is.
Health checks make or break it
A health check that only confirms the port is open will keep sending traffic to a server whose database connection has failed. A check that hits an endpoint exercising the actual dependencies will not.
Keep the endpoint cheap enough to call every few seconds, and make sure it fails when the server genuinely cannot serve requests. This one detail determines whether the load balancer improves reliability or merely spreads failures around.
If you only have one server
Do not add a load balancer to make it faster; it will not. Add capacity, add caching, or fix the slow query.
Do consider one if you are about to add a second server, if downtime during updates has become unacceptable, or if certificate management across machines is already annoying you. Those are the problems it solves, and it solves them well.