People add a load balancer when traffic grows. That is usually the weakest of the reasons to have one, and it is why load balancers are often added later than they should have been.
What you actually get
- Health checks and automatic removal. A failing server stops receiving traffic without anybody being paged. This is the feature that changes availability, and it works with two servers as well as twenty.
- Zero-downtime deployment. Drain one instance, deploy, health-check, return it, repeat. Without a balancer, every deploy is a visible interruption.
- TLS termination in one place. One certificate to renew rather than one per server, and modern cipher configuration maintained by the provider.
- A stable entry point. Instances can be replaced without touching DNS.
- Traffic distribution, which is the headline feature and the one you notice least.
Layer 4 and layer 7
A layer 4 balancer forwards TCP connections. It is fast, protocol-agnostic and knows nothing about your requests. Right for non-HTTP protocols, and for cases where the backend must see the raw connection.
A layer 7 balancer understands HTTP. It can route by path or hostname, terminate TLS, rewrite headers, and retry idempotent requests against a different backend. Right for essentially every web application.
If you are not sure, it is layer 7.
When you do not need one
- A single server where a short deployment interruption is acceptable, and no second server exists to fail over to. A balancer in front of one instance adds cost and a component without adding availability.
- A workload already behind a CDN that performs origin health checking.
- Anything where the database is the single point of failure — solving the web tier while one database instance holds everything is solving the wrong problem first.
That last case is the common one. Two application servers behind a balancer, both talking to one database, is a more complicated system with the same availability as before.
Sessions are the usual complication
The moment there are two application servers, any state stored in a server’s local memory or local filesystem becomes a bug: users hit a different machine and their session disappears.
Three ways out, in order of preference:
- Make the application stateless. Sessions in a shared store — Redis or the database — uploads in object storage.
- Signed cookies holding the session data itself, where the data is small and not sensitive.
- Sticky sessions at the balancer, which works and quietly reintroduces the problem you were solving: when that server dies, those users lose their session anyway.
Write a real health check
A health check that returns 200 whenever the web server is running will happily keep sending traffic to an instance whose database connection has failed. A useful check verifies the dependencies the instance needs to serve a request — and does not itself become so expensive that the checks are a load.
Keep it separate from the readiness question during deploys: an instance that is starting up should fail the check until it is genuinely ready.
Where to go next
- Autoscaling: what it fixes and what it hides
- What an uptime SLA actually promises
- Firewall rules for a new cloud server
Questions
Frequently asked
Do I need a load balancer for one server?
Usually not for availability, since there is nowhere to fail over to. It can still be worth it for TLS termination and zero-downtime deploys, but those are the reasons — not redundancy.
What is the difference between layer 4 and layer 7 load balancing?
Layer 4 forwards TCP connections without understanding them. Layer 7 understands HTTP and can route by path or host, terminate TLS and retry requests. Web applications generally want layer 7.
Are sticky sessions a good idea?
They are a workaround. They keep a user on one server, which means that user still loses their session when that server fails. Shared session storage is the durable fix.