Load balancing is the process of distributing incoming network requests across multiple servers, ensuring that no single server bears the full burden of handling all traffic and that the workload is spread efficiently across the available server capacity. A load balancer sits in front of a pool of servers and routes each incoming request to one of the available servers according to a distribution algorithm, preventing any individual server from becoming a bottleneck while ensuring that the application remains responsive and available even when individual servers fail or are taken offline for maintenance.

The term load balancing captures the essential purpose, balancing the load, the work of handling requests, across multiple servers so that the combined capacity of the server pool handles traffic that no single server could manage alone. A web application receiving 100,000 requests per minute that a single server could not handle might distribute those requests across 10 servers each handling 10,000 requests per minute, well within each server’s individual capacity.

Load balancing is fundamental to scalable, highly available web infrastructure. Without load balancing a web application is limited to the capacity of a single server, scaling requires upgrading to increasingly powerful single servers rather than adding commodity servers to a pool. With load balancing capacity scales horizontally, adding more servers to the pool increases capacity proportionally. Load balancing also provides fault tolerance, when one server fails the load balancer detects the failure and routes traffic to remaining healthy servers, maintaining availability without human intervention.

For redirect management load balancing is part of the infrastructure through which redirect requests flow, load balanced redirect infrastructure distributes redirect processing across multiple servers for performance and reliability. Understanding load balancing helps explain how redirect management platforms maintain high availability and handle traffic spikes.

How load balancing works

A load balancer operates as an intermediary between incoming client requests and backend server pools, making routing decisions for every request based on configured algorithms and server health.

The load balancer’s position: a load balancer sits between the internet and the backend server pool. DNS resolves the application’s domain to the load balancer’s IP address, clients connect to the load balancer believing it is the web server. The load balancer selects a backend server, forwards the request, receives the response, and returns it to the client. Clients are unaware of the backend servers, they only communicate with the load balancer.

This architectural position is similar to a reverse proxy: and indeed many reverse proxy implementations include load balancing capabilities. Nginx, HAProxy, and Caddy all function as both reverse proxies and load balancers. Cloud load balancers, AWS Application Load Balancer, Google Cloud Load Balancing, Azure Load Balancer, are managed services that provide load balancing alongside SSL termination, health checking, and traffic management.

Health checking: the load balancer continuously monitors the health of backend servers, sending periodic health check requests and removing unhealthy servers from the routing pool. Health checks verify that a server is reachable and responding correctly, a server that fails health checks is automatically removed from the pool until it recovers. Health checking enables automatic failure detection and recovery, the load balancer responds to server failures within seconds without human intervention.

Health check configuration specifies what constitutes a healthy response, typically a specific HTTP status code, 200 OK: from a designated health check endpoint. A server returning 500 errors or not responding within a timeout threshold is marked as unhealthy and removed from the pool. When the server recovers and begins returning healthy responses it is automatically re-added to the pool.

Session persistence: some applications require that a user’s requests are consistently routed to the same backend server, because session state is stored on the server rather than in a shared database or cache. Session persistence, also called sticky sessions, configures the load balancer to route all requests from a specific client to the same backend server for the duration of the session. Persistence is typically implemented through cookies, the load balancer sets a cookie identifying the target backend server and uses it to route subsequent requests from that client.

Load balancing algorithms

Load balancers use different algorithms to determine which backend server should handle each request, each algorithm has different characteristics and appropriate use cases.

Round-robin: the simplest and most common algorithm. Requests are distributed to backend servers in sequential order, server 1 gets the first request, server 2 gets the second, server 3 gets the third, then back to server 1. Round-robin assumes all requests have similar processing requirements and all servers have equal capacity. It distributes request count evenly, but not necessarily workload evenly if some requests are significantly more resource-intensive than others.

Weighted round-robin: an extension of round-robin that assigns different weights to backend servers based on their capacity. A server with weight 3 receives three times as many requests as a server with weight 1. Weighted round-robin is appropriate when servers have different hardware capabilities, more powerful servers receive proportionally more traffic.

Least connections: routes each new request to the backend server with the fewest active connections. More sophisticated than round-robin, it accounts for varying request processing times. A server handling many long-running requests has more active connections than a server that completes requests quickly, least connections routes new requests away from the busy server. Appropriate for applications where request processing times vary significantly.

Weighted least connections: combines least connections with server weighting, routing to the server with the fewest connections relative to its capacity. A powerful server with 100 connections but high capacity may receive a new request over a weaker server with only 20 connections but low capacity.

IP hash: routes requests based on a hash of the client’s IP address, the same client IP always routes to the same backend server. Provides a form of session persistence based on IP address rather than cookies. Appropriate for applications that need consistency for specific clients but do not use cookie-based sessions.

Least response time: routes requests to the server with the lowest combination of active connections and response time. More sophisticated than least connections, it considers both current load and historical performance. Appropriate for latency-sensitive applications where response time variance between servers is significant.

Random: selects a backend server randomly for each request. Simple to implement and surprisingly effective at distributing load evenly across large server pools, the law of large numbers produces even distribution over many requests even without sequential assignment.

Types of load balancers

Load balancers operate at different layers of the network stack, each layer offering different routing capabilities and performance characteristics.

Layer 4 load balancers, transport layer: operate at the TCP/UDP transport layer, routing connections based on IP address and port number without inspecting the content of the request. Layer 4 load balancers are extremely fast, they make routing decisions based on connection-level information without parsing HTTP content. However they cannot make routing decisions based on URL paths, HTTP headers, or cookies, all requests to the same IP and port are routed by the same algorithm regardless of content.

Layer 4 load balancing is appropriate for non-HTTP protocols and for HTTP applications that do not require content-based routing. It is also used as the first tier in multi-tier load balancing architectures, distributing connections across a pool of Layer 7 load balancers.

Layer 7 load balancers, application layer: operate at the HTTP application layer, parsing HTTP requests and making routing decisions based on URL paths, HTTP headers, cookies, query parameters, and other request attributes. Layer 7 load balancers can route requests to different backend pools based on content, /api/* requests to an API server pool, /static/* requests to a static file server pool, requests with a specific cookie to a canary deployment server. This content-based routing enables sophisticated traffic management that Layer 4 balancers cannot implement.

Layer 7 load balancers also perform SSL termination: handling TLS handshakes at the load balancer and forwarding decrypted connections to backend servers. SSL termination at the load balancer centralises certificate management and offloads TLS processing from backend servers.

Hardware load balancers: dedicated physical appliances designed specifically for load balancing. High performance, extremely reliable, but expensive and inflexible, hardware upgrades are required to increase capacity. Increasingly replaced by software load balancers and cloud load balancing services.

Software load balancers: load balancing implemented in software running on commodity servers. Nginx, HAProxy, and Envoy are widely used open-source software load balancers. Software load balancers are flexible, scalable, and cost-effective, running on the same hardware infrastructure as other application components.

Cloud load balancers: managed load balancing services provided by cloud platforms. AWS Application Load Balancer, AWS Network Load Balancer, Google Cloud Load Balancing, Azure Load Balancer. Cloud load balancers are fully managed, no infrastructure to provision or maintain, and integrate with other cloud services. They scale automatically with traffic and provide built-in health checking, SSL termination, and monitoring.

Load balancing and redirects

Load balancing interacts with redirect management in several ways, both as infrastructure through which redirect requests flow and as a potential layer for implementing redirect logic.

Redirect processing through load-balanced infrastructure: redirect management platforms that use load-balanced infrastructure distribute redirect processing across multiple servers. Each redirect request is routed to an available server in the pool, the server looks up the redirect rule in the shared database or cache and returns the redirect response. Load balancing ensures that redirect processing capacity scales with traffic and that individual server failures do not affect redirect availability.

Layer 7 redirect rules at the load balancer: Layer 7 load balancers that inspect HTTP request content can implement redirect rules directly at the load balancer level, before requests reach backend servers. AWS Application Load Balancer supports redirect actions, configuring the load balancer to return 301 or 302 redirect responses for specific URL patterns without forwarding requests to backend servers. This load balancer-level redirect execution is fast, the redirect response is generated at the load balancer without backend server involvement.

Session persistence and redirect consistency: for redirect management platforms that use session state to manage redirect rule updates, ensuring consistent redirect responses during rule propagation, session persistence at the load balancer ensures that requests from the same client are routed to the same backend server. Consistent routing prevents the scenario where a user’s first request receives an old redirect rule from one server and a subsequent request receives an updated rule from a different server.

Health checking redirect endpoints: load balancer health checks for redirect management infrastructure verify that redirect processing is functioning correctly, not just that the server is responding. A health check endpoint that exercises the redirect rule lookup, fetching a test redirect rule and verifying the correct response, provides more meaningful health verification than a simple ping check. Servers that fail redirect functionality health checks are removed from the pool automatically.

SSL termination for redirect domains: redirect management platforms serving traffic for many custom domains need SSL termination at the load balancer or CDN layer. The load balancer must present a valid SSL certificate for each connected domain, or use SNI-based virtual hosting to present the correct certificate for each domain. Cloud load balancers with managed certificate support, AWS Certificate Manager, Google-managed SSL certificates, automate certificate provisioning for connected domains.

Load balancing and DNS

Load balancing is closely related to DNS: DNS is often used as a simple load balancing mechanism and interacts with more sophisticated load balancing infrastructure.

DNS load balancing: the simplest form of load balancing. Multiple A records for the same domain name return different IP addresses, DNS clients receive different IP addresses on successive queries and connect to different servers. DNS load balancing is simple to implement but crude, it distributes connections evenly across IPs but cannot account for server health, actual load, or geographic proximity. A server that fails continues to receive DNS queries until its A record is removed and DNS propagation completes, potentially routing traffic to a failed server for minutes or hours.

DNS for load balancer discovery: more sophisticated architectures use DNS to resolve a domain to the load balancer’s IP address, the load balancer then distributes traffic across backend servers using more sophisticated health-aware algorithms. DNS points to the load balancer, the load balancer handles intelligent distribution.

Global load balancing with GeoDNS: global applications use DNS-based geographic routing, GeoDNS, to route users to the nearest regional load balancer. A user in Europe receives the IP address of the European load balancer while a user in the United States receives the IP address of the US load balancer. Each regional load balancer then distributes traffic across regional backend servers. This two-tier routing, DNS for geographic distribution, load balancer for server distribution, is the architecture underlying global-scale web applications.

Common load balancing configurations

Active-passive failover: two servers where one handles all traffic, active, and one is on standby, passive. If the active server fails the passive server takes over. Simple but inefficient, the passive server’s capacity is unused during normal operation. Appropriate for high-availability requirements where cost is secondary to simplicity.

Active-active cluster: all servers in the pool handle traffic simultaneously, requests are distributed across all servers. Maximum efficiency, all server capacity is utilised. Fault tolerance, the remaining servers absorb traffic if one fails. The most common load balancing configuration for production web applications.

Blue-green deployment: maintaining two identical production environments, blue and green, and switching the load balancer between them for deployments. Traffic runs on blue while green is updated with the new version. When green is ready the load balancer is switched to route traffic to green. If issues are discovered the load balancer switches back to blue instantly. Blue-green deployment enables zero-downtime deployments and instant rollback, relevant to redirect management platforms where configuration updates must be deployed without interrupting redirect serving.

Canary deployments: routing a small percentage of traffic to a new version while the majority continues to the existing version. The load balancer sends 5% of requests to the canary server pool running the new version, monitoring for errors before gradually increasing the percentage. Canary deployments reduce deployment risk by limiting the impact of bugs in new versions to a small traffic fraction.