What Is a Load Balancer? One Bad Night Explained

TL;DR: A load balancer is a traffic cop that splits visitors across several servers so no single machine gets crushed. In the project below, three cheap servers plus one balancer survived a traffic spike that had already knocked the old single server offline.

Last March, a friend's candle shop got a surprise mention on a local TV segment. Her site jumped from about 200 visitors an hour to 8,000 in fifteen minutes. Then the screen went white. Nothing was hacked. One rented computer was simply trying to serve thousands of people at once.

So, what is a load balancer?

It's a piece of software, or a service you rent, that sits in front of your servers and picks which one handles each visitor. A server, in plain terms, is a computer in a data center running your site. Hers cost $24 a month.

Picture a supermarket with one till open. Ten shoppers is fine. Two hundred and the queue wraps around the aisle. A load balancer is the person at the front saying "till three is free, go there." The tills are your servers. The greeter is the balancer.

The real project: three servers and an NGINX balancer

We rebuilt the shop on three small cloud servers (about $8 each, weaker than the old big one) and put one balancer in front. That's cheaper and safer than buying a single giant machine, because three small servers can fail one at a time.

The balancer runs NGINX, free software that was already serving her pages. Here's how it works in practice:

• Round robin: visitor one goes to server one, visitor two to server two, then back to the start.
• One address: customers type the same URL; the three machines stay invisible.
• Offloaded files: images and stylesheets moved to cheap storage, so servers only handle orders.

Health checks: it spots a dead server before you do

Every five seconds, the balancer sends each server a tiny test request. Miss three in a row and that server is quietly dropped from rotation until it answers again.

During testing we killed one server mid-order. The site paused for a second. No error page, no lost carts.

The catch nobody warns you about: logins

Here's the part that bit us. Login state (a session) lives in one server's memory by default. Send the customer's next click to a different server and they're logged out mid-checkout.

You have two fixes. Sticky sessions pin each browser to one server; fast to set up, but that server gets overloaded if a popular customer keeps refreshing. The better fix is a shared session store like Redis, which works like a notebook all three servers read from. We ran sticky sessions for a month, then switched to Redis.

What this means for you

Don't buy a load balancer to fix slow code. Under roughly 50,000 visits a month, one decent server, caching and real backups will do more per dollar. A balancer spreads traffic; it doesn't make your app faster.

When you do need one, rent a managed service instead of running your own. AWS's Application Load Balancer starts around $20 a month plus usage, and it handles the fiddly parts like certificates and failover. Check current pricing before you commit.

One warning worth repeating: two servers do not make a load-balanced setup. They make a single point of failure with a spare.

Key Takeaways

• A load balancer spreads visitors across several servers so no single machine crashes.
• Three small servers usually beat one big one, because they fail one at a time.
• Health checks pull broken servers out of rotation automatically.
• Move login sessions out of server memory (into Redis) before you add a second server.

Frequently Asked Questions