What Is Load Balancing?

Load balancing is the practice of distributing incoming web traffic across multiple servers so that no single machine handles more than its fair share. Instead of sending all requests to one server, a load balancer sits in front of your infrastructure and routes each request to whichever server in the pool is best placed to handle it.

The result is better performance under heavy traffic, improved reliability, and the ability to scale your infrastructure horizontally by adding more servers rather than endlessly upgrading a single machine.

How a Load Balancer Works

Without load balancing, every visitor request goes to one server. That server handles everything: processing PHP, querying the database, serving files, managing sessions. As traffic grows, so does the pressure on that single machine. Eventually it becomes a bottleneck.

With a load balancer in place, the architecture looks like this:

1. A visitor’s request arrives at the load balancer
2. The load balancer selects a server from the available pool based on its algorithm
3. The request is forwarded to that server
4. The server processes the request and sends the response back through (or directly to) the visitor
5. The load balancer monitors server health and removes any servers that become unavailable

From the visitor’s perspective, nothing changes. They still see your domain, still get a response. The distribution happens invisibly behind the scenes.

Load Balancing Algorithms

Load balancers use different algorithms to decide which server gets each request. The choice of algorithm affects performance, session handling, and resource utilisation.

Round Robin: The simplest approach. Requests are distributed in rotation: server 1, server 2, server 3, server 1 again, and so on. Equal distribution regardless of server load. Works well when all servers have identical specifications and typical request duration is consistent.

Weighted Round Robin: Like round robin, but servers are assigned weights based on their capacity. A server with twice the RAM and CPU might get twice the requests. Useful when your pool contains servers with different specs.

Least Connections: The request goes to whichever server currently has the fewest active connections. More intelligent than round robin because it accounts for the fact that some requests take longer to process than others. A server handling a slow database query doesn’t get overloaded with new requests in the meantime.

IP Hash: The server is determined by a hash of the visitor’s IP address. The same IP always goes to the same server. Useful for maintaining session state when you can’t use a centralised session store.

Resource-Based: Routes requests based on actual server metrics like CPU usage and available memory. Requires the load balancer to collect health data from each server. The most intelligent approach but also the most complex to configure.

Load Balancing and High Availability

Load balancing is closely tied to high availability. When you have traffic distributed across multiple servers, losing one doesn’t take your site offline.

The load balancer continuously health-checks each server in its pool. If a server fails to respond, the load balancer removes it from rotation and directs all traffic to the remaining healthy servers. Once the failed server recovers (or is replaced), it’s added back to the pool.

This is fundamentally different from a single-server setup where a hardware failure means downtime until the problem is resolved. With load balancing and at least two servers, you have redundancy built in. As long as one server is healthy, your site stays online.

Types of Load Balancers

Hardware load balancers: Dedicated physical devices built specifically for traffic distribution. Used by large enterprises with very high traffic volumes. Expensive and complex to manage. Rarely relevant for typical web hosting scenarios.

Software load balancers: Applications running on standard server hardware. Nginx and HAProxy are the most common examples. Nginx is particularly popular because many servers already run it as a web server; adding load balancing configuration is relatively straightforward.

Cloud load balancers: Managed services offered by cloud providers. AWS Elastic Load Balancer, Google Cloud Load Balancing, and Cloudflare Load Balancing are examples. The provider handles the infrastructure; you configure routing rules through a dashboard. Easier to set up and scale than self-managed solutions.

DNS-based load balancing: Round-robin DNS returns multiple IP addresses for a domain, distributing traffic across servers at the DNS level. Simple but limited: it doesn’t check server health, doesn’t adapt to load, and doesn’t account for DNS caching. Used as a basic approach or alongside other methods.

Session Persistence and Load Balancing

One complication with load balancing is session state. Many web applications store session data on the server: shopping cart contents, login status, form progress. If a user’s requests are routed to different servers, each server won’t have the session data stored on the others.

There are three main approaches to solving this:

Sticky sessions (session persistence): The load balancer remembers which server each user was sent to and keeps routing their requests there. Simple to implement but undermines the load distribution benefits: if one server gets all the long-duration sessions, it can become overloaded.

Centralised session storage: Sessions are stored in a shared database or cache (Redis is the most common choice) that all servers can access. Any server can handle any request because session data is available to all of them. This is the recommended approach for serious multi-server setups.

Stateless application design: Applications designed to carry no server-side session state. Each request contains all the information needed to process it. No session storage problem to solve. This is increasingly common with API-based architectures but requires significant application changes on existing systems.

Load Balancing and WordPress

Running WordPress behind a load balancer requires some specific considerations.

File storage: WordPress stores uploaded media in the wp-content/uploads directory. If each server has its own copy of this directory, uploads to one server won’t be visible from the others. Solutions include a shared network file system (NFS) or offloading media storage to an object storage service like Amazon S3.

Session handling: WordPress uses PHP sessions and database-stored options. A centralised Redis object cache shared between servers resolves most WordPress-specific session challenges.

Admin and cron: WordPress admin requests and WP-Cron jobs should generally be routed to a designated server to avoid duplication. Some load balancers support routing rules to direct /wp-admin/* requests to a specific server.

Database: A single database server shared by all web servers, or a replicated database setup with a primary for writes and replicas for reads. Database load balancing is a separate discipline from web server load balancing.

For most WordPress sites, you don’t need load balancing. A single well-configured server with good caching handles substantial traffic. Load balancing becomes relevant when you’re consistently hitting the limits of vertical scaling (more RAM, faster CPU on one machine) and need to scale horizontally instead.

When Does a Site Need Load Balancing?

Signs that load balancing might be worth considering:

• A single server is consistently running near its CPU or RAM capacity during peak hours
• Traffic spikes (a viral post, a product launch) regularly cause slowdowns or downtime
• You need to perform server maintenance without taking the site offline
• You require high availability guarantees for a business-critical site
• You’ve maxed out the vertical scaling options on your current server

For most small to medium sites, a VPS with good caching and a CDN handles traffic more cost-effectively than a load-balanced multi-server setup. Load balancing adds infrastructure complexity. It’s the right solution when you genuinely need it, not something to add prematurely.

Frequently Asked Questions

Is a CDN the same as load balancing? They overlap in some ways but serve different purposes. A CDN distributes static assets (images, CSS, JavaScript) to edge servers around the world to reduce latency for visitors. A load balancer distributes dynamic requests across multiple origin servers. CDNs often include basic load balancing features, and enterprise CDN products blur the line further. For most sites, a CDN addresses the main performance concerns without requiring a full multi-server load-balanced setup.

Does cloud hosting include load balancing? Cloud hosting typically distributes workloads across multiple underlying servers, which provides some of the same resilience benefits as load balancing. Whether a specific cloud hosting plan includes a proper load balancer depends on the provider and the plan. Managed platforms like Kinsta and WP Engine include load balancing as part of their infrastructure.

How does load balancing affect SSL? SSL termination can happen at the load balancer level (the load balancer decrypts traffic and communicates with backend servers over HTTP) or end-to-end (traffic is encrypted all the way to the backend servers). Load balancer SSL termination is simpler but requires trusting the internal network. End-to-end encryption is more secure but requires SSL certificates on every backend server.

Can I add load balancing to shared hosting? No. Load balancing is an infrastructure feature that requires control over multiple servers. It’s not available on shared hosting. It’s relevant for VPS, dedicated server, and cloud infrastructure setups.