Redundancy is a property of a design. Availability is what a visitor experiences. The layer that converts one into the other is the load balancer, and most availability failures in otherwise well-designed estates happen there rather than in the redundancy itself.
This page covers the operational mechanics: what load balancers do, the decisions they force, and the configurations that turn redundant infrastructure into an outage. The design discipline that sits above it is covered in Designing Infrastructure for High Availability.
Distributing traffic is the lesser job
Spreading requests across servers is what load balancers are named for and is the smaller half of what they contribute. The half that produces availability is removing a failed backend from rotation, and then putting it back when it recovers.
That means the health check is the load balancer's most important setting, and it is routinely the least considered one. Everything else can be correct and an inadequate health check will still route users to a broken server indefinitely.
What a health check should actually test
A check that confirms a TCP port is open tests that the process is running. A check that requests a page and accepts any response tests that the web server is answering. Neither tests that the application works.
A meaningful check exercises a path that depends on what the application depends on, and returns a failure status when that dependency is unavailable. The tension is that a check reaching too far turns a shared dependency failure into every backend being marked unhealthy at once, which is worse than serving degraded responses. The usual resolution is two checks: a shallow one for rotation, and a deeper one for alerting.
Layer 4 and layer 7 are different tools
A layer 4 balancer forwards connections without inspecting them. It is fast, protocol-agnostic and knows nothing about what it is carrying. A layer 7 balancer understands the request and can route on path or host, terminate TLS, rewrite headers, retry a failed request and serve a maintenance response.
The trade is visibility and control against latency and cost. Most web estates want layer 7 at the edge for the routing and the observability; most database and non-HTTP traffic wants layer 4 because there is nothing useful to inspect.
Sessions are what make load balancing hard
If a request can be served by any backend, load balancing is straightforward. If the application stores state in the backend's memory, it is not, because the second request has to reach the same machine.
Sticky sessions solve it and create the problem the redundancy existed to prevent: when the machine fails, its users lose their sessions. The durable answer is to move session state somewhere shared, so that any backend can serve any request and a failure costs nothing visible. That is an application change rather than an infrastructure one, which is why it is often deferred and why it is usually the right investment.
Algorithms matter less than people expect
Round robin, least connections and weighted variants differ in ways that are mostly invisible when backends are identical and requests are uniform. They start to matter when either assumption breaks: mixed instance sizes, or a workload where some requests take a hundred times longer than others.
Least connections handles uneven request cost better than round robin. Weighting handles uneven backend capacity. Neither compensates for a backend that is failing slowly rather than cleanly, which is what the health check is for.
TLS termination is a decision about where trust ends
Terminating TLS at the load balancer centralizes certificate management and gives the balancer visibility into the request, which is what makes layer 7 routing possible. It also means traffic behind the balancer is unencrypted unless it is re-encrypted deliberately.
For most estates, terminating at the edge and re-encrypting to the backend is the right balance. For estates with a regulatory obligation about data in transit, or a network they do not fully control, it is not a balance at all. Certificate expiry remains the most predictable outage in infrastructure, so wherever termination happens, renewal should be automated and expiry monitored rather than remembered.
Connection draining is the difference between a deploy and an incident
Removing a backend abruptly cuts every request in flight. Draining stops sending new connections while allowing existing ones to complete, which turns a deployment or a scale-down from a visible error into a silent one.
The setting people get wrong is the timeout: shorter than the longest legitimate request and long requests are still cut, longer than the deployment window and the deployment stalls. Knowing the actual distribution of request durations is what makes the number defensible.
Failover capacity is the arithmetic that gets skipped
Two servers each running at 60 percent are comfortable until one fails, at which point the survivor needs 120 percent of itself. The design was redundant and the capacity was not, and the result is a cascading failure that looks like a load balancer problem.
The rule is that surviving capacity has to carry peak load, not average load, and that the calculation has to be redone whenever the estate grows. Autoscaling helps and does not eliminate the problem, because scaling takes minutes and the failover takes seconds.
The load balancer is also a single point of failure
Putting everything behind one device to improve availability is a recognizable irony. Managed cloud balancers are redundant internally and the concern largely goes away; self-managed appliances need a pair with a tested failover, and the failover needs exercising, because the standby that has never taken traffic is a standby nobody has tested.
The related question is what the balancer depends on. A balancer whose configuration is fetched from a system that is down, or whose health checks traverse a link that is saturated, has more failure modes than it appears to.
Retries help, until they do not
A layer 7 balancer can retry a failed request against another backend, which hides transient faults from users and is usually worth having. The caveat is that retries multiply load at exactly the moment the estate is least able to absorb it, so a backend struggling under pressure receives more traffic because it is struggling.
Two settings keep that from compounding: a retry budget that caps retries as a fraction of total requests rather than allowing one per failure, and a rule that only requests which are safe to repeat get retried at all. A retried payment is a worse outcome than a failed one.
DNS distributes traffic, slowly
Routing at the DNS layer spreads traffic across regions or sites, which is the tool for geographic distribution. Its weakness is the one covered in Network Infrastructure Management: resolvers cache, so the time to move traffic is the time-to-live plus however long clients ignore it.
That makes DNS a good mechanism for planned distribution and a poor one for fast failover. Estates needing rapid regional failover usually put an anycast or global balancing layer in front and use DNS for the slow-moving part.
Cloud platforms describe the same principles
Provider guidance converges on the same practices. Amazon's reliability guidance opens by noting that in the cloud, there are a number of principles that can help you increase reliability, and the principles it lists are the ones above expressed as platform features: automatic recovery from failure, testing recovery procedures, and horizontal scaling to increase aggregate availability. See AWS Well-Architected Framework, Reliability Pillar.
Microsoft's equivalent is framed physically, defining an availability zone as a logical grouping of one or more physically separate datacenters within a region, each with independent power, cooling and networking. See Microsoft, What are availability zones?. Distributing backends across zones is the cloud expression of not putting the redundant pair in the same rack.
Observability, or the balancer is a black box
The load balancer sees every request and is therefore the best vantage point in the estate. Backend health transitions, per-backend error rates, response time distributions and connection counts are all available at that layer and all of them are leading indicators.
Health transitions are the most useful and the least watched. A backend flapping in and out of rotation is serving intermittent errors to a fraction of users, which is invisible in an availability average and obvious in the transition log. Where this reporting belongs is covered in Infrastructure Monitoring and Management.
Testing failover, deliberately
A failover that has never been performed is a configuration, not a capability. Removing a backend during a quiet period and watching what happens takes minutes and answers questions no review can: whether the check notices, how long it takes, whether users saw anything, and whether the survivors coped.
Doing it regularly rather than once is what keeps the answer current, because capacity, request mix and the estate all change underneath a result that was true a year ago. LABUSA's managed approach to availability describes how this sits alongside monitoring, capacity and recovery planning.