Load Balancing and High Availability, Explained

What a load balancer actually buys you

A load balancer is the device or service that sits in front of a pool of servers, accepts every client request, and decides which backend serves it. That single decision point does two jobs at once. It spreads load horizontally, so you scale by adding commodity servers instead of buying one ever-larger machine. And it removes the server from the critical path: when a backend fails, the load balancer stops sending it traffic and users never notice. High availability is the direct consequence — no single server is allowed to be a single point of failure.

The catch is that the load balancer can become the single point of failure it was meant to eliminate. Every design decision below assumes you have paired the load balancers themselves, so we start from there and work outward. High availability is not one feature you switch on; it is a chain of independent choices about how traffic is steered, how failure is detected, and what happens when a backend, a whole tier, or an entire site goes dark.

Layer 4 versus Layer 7

The first choice is where in the stack the load balancer makes its decision, and it is a genuine tradeoff, not a "newer is better" upgrade.

Layer 4 (transport). The balancer routes on IP address and TCP or UDP port without inspecting the payload. It is fast, cheap on CPU, and protocol-agnostic — it will happily balance a database, a game server, or raw TCP. It cannot make decisions based on a URL, a cookie, or a host header because it never reads them.

Layer 7 (application). The balancer terminates the connection, reads the HTTP request, and routes on content: send /api to one pool and /images to another, split by hostname, rewrite headers, or terminate TLS centrally. You get far smarter routing and features like content caching and web-application-firewall inspection, at the cost of more CPU per request and a device that now understands your protocol.

Figure: the balancer is the hub every request passes through — which is exactly why it must be paired, or it becomes the single point of failure it was meant to remove.

Most enterprise web workloads want Layer 7 for the routing intelligence and central TLS handling. Reserve Layer 4 for high-throughput, non-HTTP, or latency-sensitive traffic where you cannot afford to terminate and re-open connections. Many designs use both: Layer 4 at the edge for raw scale, Layer 7 deeper in for application logic. This is the pattern we build into managed cloud environments, where the platform's native Layer 4 and Layer 7 balancers can be combined instead of forcing one to do the other's job.

Algorithms and health checks

Once traffic arrives, the balancer needs a rule for picking a backend. The common algorithms trade simplicity for awareness of real server state:

• Round robin hands each new request to the next server in order. Simple and fair only when every server and every request is roughly identical.
• Weighted round robin assigns more traffic to bigger servers — the right call in a mixed fleet where a new 32-core node sits beside older hardware.
• Least connections sends the next request to whichever server has the fewest active connections. It adapts to reality when request durations vary widely, which they almost always do.
• Least response time and hash-based methods add latency awareness or pin a client consistently to a backend by source IP or another key.

None of this matters without health checks, which are what make the whole thing highly available rather than just balanced. The balancer probes each backend and pulls unhealthy ones from rotation automatically. The depth of the check is what separates a real safeguard from a comforting illusion:

1. Passive checks watch live traffic for errors and timeouts — free, but only after real users have already hit the failure.
2. Active TCP checks confirm the port accepts a connection. Cheap, but a server can accept connections while its application is wedged.
3. Active application checks request a real health endpoint and validate the response body or status code. This is the one that catches the dangerous case: a server that is up on the network but broken for users.

Tune the thresholds deliberately. Requiring two or three consecutive failures before ejecting a node avoids flapping on a single blip; a fast re-check interval brings it back quickly once healthy. Wiring those probes into infrastructure monitoring means the same signal that reroutes traffic also alerts a human, so a quietly degrading pool gets fixed before it runs out of healthy members.

Session persistence, and why it is a liability

Some applications store session state in server memory, so a user must keep landing on the same backend or they get logged out mid-checkout. Load balancers solve this with persistence — a "sticky" cookie or a source-IP hash that pins a client to one server.

Persistence works, but treat it as a constraint you are managing, not a feature you want. It undermines even load distribution, and it directly weakens availability: when a sticky server dies, every session pinned to it is lost, not gracefully moved. The better long-term fix is to make backends stateless — push session state into a shared cache or datastore so any server can handle any request. Then persistence becomes an optimization, not a dependency, and losing a node costs a retry instead of a logout.

Active-active versus active-passive

The same redundancy question applies to the balancers and the sites behind them.

Active-passive. One node or site serves production; the standby waits and takes over on failure. It is simpler and cheaper, and it is right for many workloads. The weakness is the standby itself — a path that only carries traffic during a disaster is a path whose health you are usually guessing at, plus you pay for capacity that sits idle until the worst day.

Active-active. Every node and site carries production traffic and shares load; survivors absorb the failed member's share. You continuously prove all paths work because none is ever idle, and there is no cold-start moment. The cost is that you must size each path to run the full load alone (or accept degraded capacity during a failure) and solve harder problems around shared state and consistency. Choose active-active for revenue-critical paths and reserve active-passive where a short switch window is acceptable and full duplicate capacity is not worth it.

Global server load balancing and cross-site failover

Local balancing protects you from a dead server. It does nothing when the whole data center, region, or ISP goes down. Global server load balancing (GSLB) operates at the DNS layer, resolving your name to whichever site is healthy and closest, and steering users away from a failed region entirely.

• Health-based failover. GSLB probes each site and stops returning the address of one that fails, moving traffic to a surviving region.
• Geographic routing. Users resolve to the nearest healthy site, cutting latency as a bonus of the same mechanism.
• DNS TTL realities. Failover is only as fast as your TTL and how well resolvers and browsers honor it. Keep TTLs low enough to fail over in minutes, but not so low you hammer your DNS infrastructure — and never depend on a single DNS provider.

Multi-site GSLB is the backbone of the resilient global networks we operate for clients who cannot let a regional outage take down operations everywhere, and it is a core piece of any serious business continuity plan.

Design for graceful degradation

The last discipline is deciding what a partial failure looks like, because the choice is never really up or down. When a pool loses half its capacity, does it serve everyone slowly, shed the least important traffic to protect checkout, or return a lightweight static page instead of an error? A load balancer that can drain connections during maintenance, cap concurrent requests, and fail over to a read-only or reduced-feature mode turns a hard outage into a soft, survivable one.

• Drain nodes gracefully for deploys and patching instead of cutting live sessions.
• Shed or queue low-priority traffic first so critical paths keep working under load.
• Serve a cached or static fallback rather than a blank error when backends are gone.

Get high availability that holds under real failure

Load balancing is how modern infrastructure stays available — but only when the balancers are paired, the health checks are deep enough to catch a wedged server, sessions do not tie you to one node, and cross-site failover has actually been tested under load. intSignal designs, builds, and operates load-balanced, highly available infrastructure and proves it holds when a server, a tier, or a whole site fails. Talk to our team to map your single points of failure and design them out before your next outage does it for you.