Every application has a traffic ceiling. Below that ceiling, a single server handles all requests without strain. Above it, response times climb, errors appear, and users leave. Server load balancing is the infrastructure technique that raises the ceiling, distributing incoming traffic across multiple machines so that no single one carries the entire workload.
This guide explains how the algorithms and load balancer types differ, when a single server stops being sufficient, and why the performance of a balanced pool depends entirely on the performance of its weakest member.
📖 New to server infrastructure?
Before exploring traffic distribution, it helps to understand what sits behind the load balancer. Read What Is a Dedicated Server?, a complete introduction to how dedicated infrastructure works and why it forms the foundation of scalable hosting.
What Server Load Balancing Actually Does
Server load balancing distributes incoming network traffic across multiple backend machines so that no single one becomes a bottleneck. A device or software component called a load balancer sits between the client and the server pool, receives every incoming request, and routes each one to the most appropriate backend according to a defined algorithm.
Without it, all traffic goes to one machine. When that machine reaches its capacity, whether in CPU, RAM, network bandwidth, or concurrent connections, performance degrades for every user simultaneously. Furthermore, if it fails, the entire application goes offline.
Load balancing addresses both failures at once. It spreads work across several machines, preventing any one from saturating, and it provides redundancy: when one backend fails, the load balancer routes traffic to the remaining healthy ones automatically.
Consequently, the application scales horizontally rather than vertically. Instead of buying a larger machine every time traffic grows, you add another to the pool. The load balancer handles distribution transparently, and clients notice nothing.
📖 What does server load actually measure?
Before distributing traffic, diagnose which resource is saturating. Read What Is Server Load and Why Websites Slow Down, covering load metrics, what causes traffic spikes, and how to identify the actual bottleneck before adding servers.
The Request Flow, Step by Step
Every client request follows the same sequence once a load balancer is in place.
1. The request arrives. A browser or application sends a request to your domain. DNS resolves that domain to the IP address of the load balancer, not to any individual backend.
2. The load balancer inspects it. Depending on its type, it reads the source IP, the protocol, the headers, or the URL path, then applies its routing algorithm to select a backend.
3. The request is forwarded. The load balancer passes the request to the chosen machine, typically preserving the original client IP in an X-Forwarded-For header so the application can log it correctly.
4. The backend responds. The chosen machine processes the request and returns its response through the load balancer to the client. Some architectures use Direct Server Return, where the response travels straight from the backend to the client, reducing the throughput the load balancer must handle.
5. Health checks run continuously. The load balancer sends periodic health check requests to every backend. Machines that fail leave the rotation automatically, and rejoin it when they recover.
How Traffic Gets Distributed: The Algorithms
The algorithm decides which backend receives each request. Different algorithms suit different workload shapes, and choosing badly wastes capacity.
Round Robin
Round Robin distributes requests sequentially across the pool. The first goes to server A, the second to B, the third to C, and then the cycle repeats.
It works well when every machine has equivalent hardware and requests consume roughly similar resources. Being the simplest algorithm, it is the default in most load balancers.
However, Round Robin becomes inefficient when machines differ in capacity or when requests vary in complexity. A long-running database export and a trivial API health check both count as one request in the rotation, yet they consume radically different resources.
Weighted Round Robin
Weighted Round Robin assigns each machine a weight proportional to its capacity. A server with twice the CPU and RAM receives twice as many requests per cycle.
This suits heterogeneous pools: a mix of high-specification and lower-specification machines, or a gradual migration to newer hardware while older machines remain in service.
Least Connections
Least Connections routes each new request to whichever machine currently holds the fewest active connections. Rather than following a fixed sequence, it adapts to the live distribution of load.
For workloads where request duration varies significantly, this performs better than Round Robin. Large file downloads, streaming connections, and database queries against large datasets all hold connections open for extended periods. Least Connections notices, and directs new requests away from machines that are already busy.
Weighted Least Connections
Weighted Least Connections combines the capacity-awareness of the weighted approach with the dynamic adaptation of Least Connections. Each machine carries a weight, and the algorithm routes to whichever has the lowest ratio of active connections to weight.
It is the most sophisticated of the common algorithms, and in production environments with mixed hardware and variable request durations, it consistently performs best.
IP Hash
IP Hash derives the backend from the client’s IP address. The same address always reaches the same machine, which creates session persistence without requiring the application to share state between servers.
This helps when session state lives locally on each application server rather than in a shared store. Nevertheless, it distributes load unevenly if a small number of clients generate disproportionate traffic, and it breaks when clients change IP address mid-session, which happens constantly on mobile networks.
Content-Based Routing
Advanced load balancers route on URL path, HTTP headers, or cookie values. A single load balancer can therefore direct different traffic types to specialised pools: API requests to one pool, static file requests to another, administrative traffic to a machine reserved for it, and mobile user agents to a mobile-optimised backend.
This architecture suits microservices applications particularly well, because different components have different scaling requirements and benefit from being scaled independently.
📖 Which CPU should each backend server have?
A balanced pool performs only as well as its weakest member. Read How to Choose the Right CPU for Your Dedicated Server, covering core count, clock speed, and which matters for concurrent request handling.
Types of Load Balancer
Load balancing happens at different layers of the network stack, and through different deployment models.
Layer 4 and Layer 7
Layer 4 load balancing operates at the transport layer. It routes on IP addresses and TCP or UDP ports without inspecting the content of the traffic. Layer 4 balancers are extremely fast, processing millions of packets per second with minimal added latency, but they cannot make content-aware decisions.
Layer 7 load balancing operates at the application layer. It inspects the full HTTP request, including URL, headers, cookies, and body, before deciding where to send it. This enables content-based routing, SSL termination, compression, and application-aware health checks. The cost is higher processing overhead.
For most web applications, Layer 7 is the appropriate choice, because modern application architectures depend on the content-awareness it provides.
Software Load Balancers
Software balancers run on standard server hardware and distribute traffic through application software. Two dominate production deployments.
Nginx functions as a high-performance reverse proxy and load balancer, supporting Round Robin, Least Connections, IP Hash, and their weighted variants. In addition, it handles SSL termination, HTTP/2, gzip compression, and static file serving, which makes it a complete application delivery platform rather than a load balancer alone.
HAProxy is a dedicated load balancer and proxy optimised for high availability and throughput. Compared to Nginx, it offers more sophisticated health checking, more detailed metrics, and more granular configuration for pure load balancing. In high-traffic production environments where load balancing is the primary function, HAProxy is the standard choice.
Hardware Load Balancers
Hardware balancers are dedicated physical appliances built specifically for traffic distribution. They deliver extremely high throughput and low latency, processing millions of connections per second with hardware-accelerated SSL offloading.
They are also expensive and inflexible, and software solutions running on dedicated hardware increasingly displace them, delivering comparable performance at a fraction of the cost.
Cloud Load Balancers
Major cloud providers offer managed balancing services: AWS Elastic Load Balancer, Google Cloud Load Balancing, Azure Load Balancer. These integrate tightly with the surrounding cloud infrastructure and scale automatically.
The trade-offs mirror those of every managed cloud service. Egress fees scale with traffic volume, configurability is narrower than a self-managed equivalent, and the cost structure compounds as scale increases.
Session Persistence, and Why You Probably Want to Avoid It
Some applications store user state locally on the application server: shopping cart contents, authentication tokens, partially completed forms. When traffic distributes across several machines, a user whose session lives on server A finds that server B has no record of them when the next request arrives there.
Session persistence, also called sticky sessions, solves this by routing a user’s requests consistently to the same backend for the duration of their session.
Two implementations are common. Cookie-based persistence has the load balancer insert a cookie identifying the assigned backend, which subsequent requests carry. IP-based persistence routes on client IP, and proves unreliable for mobile clients whose addresses change frequently.
However, persistence distributes load unevenly whenever some users hold longer or more active sessions than others. Worse, it undermines the failover benefit: when a machine fails, every user with a session on it loses their state.
The cleaner architecture removes session state from the application server entirely, into a shared Redis instance that every machine in the pool can reach. With shared session storage, any machine handles any request from any user, persistence becomes unnecessary, and failover is seamless.
Load Balancing and High Availability
Load balancing is the foundation of high availability. By distributing traffic, it ensures that no single machine failure takes the application offline. A production-grade architecture layers four kinds of redundancy.
Multiple application servers sit behind the load balancer. When one fails a health check, it leaves the rotation and its traffic redistributes across the survivors, without interrupting users.
Load balancer redundancy matters because the load balancer itself is a single point of failure. Serious deployments run two in active-passive configuration, with a virtual IP address transferring to the secondary within seconds via VRRP or CARP when the primary fails.
Database tier redundancy is necessary because balancing the application tier helps nothing if the database is the single point of failure. Primary-replica configurations allow the replica to be promoted when the primary fails.
Geographic redundancy replicates the entire stack across data centres in different locations, with DNS-based global load balancing routing users to the nearest available one. This is the highest tier, and the most expensive.
📖 What does high availability actually require?
Redundancy at one tier is not redundancy at all. Read High Availability Hosting Explained, covering failover mechanisms, redundancy layers, and what uptime figures actually promise.
When Does Your Application Need Load Balancing?
Load balancing is not required at every stage of growth, and implementing it early buys complexity without benefit.
You probably do not need it yet if a single well-configured dedicated server handles your peak traffic with CPU and RAM below 60%, if your traffic is predictable rather than spiky, and if a single machine with automated failover and frequent backups already satisfies your availability requirements.
You do need it once peak traffic consistently pushes CPU or RAM above 80% on one machine, once spikes produce response time degradation or 503 errors, once your SLA demands zero-downtime deployments or faster failover than a single machine can provide, or once per-server capacity has become the constraint on growth for a SaaS or e-commerce platform.
The choice between scaling vertically and scaling horizontally depends on workload shape. Database-heavy applications often gain more from a larger single machine, because a bigger buffer pool holds more of the working dataset in memory. Application tiers handling many concurrent stateless requests, by contrast, scale more naturally by adding machines behind a load balancer.
Why the Backend Hardware Determines the Ceiling
A load balancer distributes work across a pool. The performance of that pool is bounded by its weakest member, and the performance of each member is determined by its hardware and its configuration.
This is why dedicated servers form the natural foundation for balanced architectures.
Exclusive hardware resources mean no shared CPU, no shared RAM, and no noisy neighbour effect. The load balancer can rely on each machine delivering consistent, predictable performance, because no external workload degrades it.
Configurable resource allocation means PHP-FPM worker pools, database connection limits, network buffer sizes, and kernel parameters can each be tuned for the specific role a machine plays. An application server and a database server want fundamentally different configurations, and dedicated infrastructure permits both.
Predictable cost at scale means adding a machine to the pool adds a fixed, known monthly figure. Adding cloud instances adds variable cost that scales with traffic, plus egress fees for the inter-instance communication that balanced cloud architectures generate continuously.
Build your load-balanced pool on dedicated infrastructure
Swify dedicated servers give every machine in your pool exclusive CPU and RAM, enterprise SSD and NVMe storage options, and 1Gbps unmetered bandwidth from a Netherlands data centre connected to AMS-IX. Fixed monthly pricing, no egress fees between servers, from €120/month.
→ Explore Swify Dedicated ServersFrequently Asked Questions
What is the difference between load balancing and a CDN?
A Content Delivery Network distributes static content, such as images, CSS, JavaScript, and video, from edge locations geographically close to users, reducing latency for asset delivery. Load balancing distributes dynamic application requests across multiple backend servers so that no single one becomes overloaded. They solve different problems at different layers.
Most production architectures use both simultaneously. The CDN handles static asset delivery from the edge, while the load balancer distributes dynamic requests across the application pool at the origin. Neither substitutes for the other: a CDN cannot cache authenticated pages, and a load balancer cannot move content closer to the user. Read more in What Is a Content Delivery Network (CDN) and Why Your Site Needs It.
What is the best load balancing algorithm for a web application?
For most web applications with homogeneous server pools and relatively uniform request durations, Least Connections is the most reliable default. It adapts dynamically to the live load distribution and outperforms Round Robin whenever requests vary in complexity, which they almost always do.
If the pool mixes hardware specifications, Weighted Least Connections accounts for the capacity differences and distributes accordingly. IP Hash is appropriate only when the application requires session persistence and shared session storage is not an option, because it distributes load unevenly and breaks for clients whose IP address changes mid-session. Read more about matching hardware to workload in How to Choose the Right CPU for Your Dedicated Server.
Can load balancing prevent server downtime?
Load balancing significantly reduces the impact of individual server failures, but it does not eliminate downtime risk. When a backend fails, health checks detect it and remove it from rotation, redistributing its traffic across the healthy machines, typically within seconds. Users notice nothing.
However, the load balancer itself becomes the single point of failure unless it runs as a redundant active-passive pair. Similarly, a balanced application tier provides no protection when the database behind it is a single machine. The most resilient architecture combines load balancing with redundant load balancers and database replication, and each layer added has a cost that must be weighed against the availability it buys. Read more in Understanding Server Uptime, SLAs, and Reliability Metrics.
How many servers do I need for load balancing?
Two backend servers is the minimum for meaningful load balancing, providing both traffic distribution and basic failover. That configuration carries a hidden cost, though: if one fails, the survivor must handle 100% of traffic indefinitely, which means it has to be capable of running at full capacity alone.
Three or more machines provide more comfortable headroom, because when one fails the remaining ones each absorb a manageable fraction of the lost traffic. The right number follows from your current peak utilisation. A single machine running at 60% at peak suggests two equivalent machines gives comfortable headroom. One running at 90% suggests three is the safer starting point. Read more about diagnosing where your current server stands in What Is Server Load and Why Websites Slow Down.
What is the difference between load balancing and server clustering?
The two are related but distinct. Load balancing distributes incoming requests across a pool of servers that each run independently, with every machine handling complete requests on its own. Clustering refers to servers that share state and operate as a coordinated unit, often through shared storage or shared memory.
In practice, modern web applications combine both. A load balancer distributes traffic across independent application servers, while the database tier uses primary-replica replication for redundancy, which is a form of clustering. For most applications, load balancing at the application tier with session state in a shared Redis instance is simpler, cheaper, and more effective than true application clustering. Read more about how virtualisation and clustering differ in What Is Server Virtualization and Why Does It Matter?
Does load balancing improve website speed and SEO?
Load balancing improves speed by preventing individual machines from saturating during traffic spikes, which is precisely when performance degrades most visibly. Consistent response times under load directly improve Time to First Byte, which Google measures as a component of Core Web Vitals and uses as a ranking signal.
Indirectly, it also supports SEO by enabling zero-downtime deployments. You update one machine at a time while the others continue serving, which eliminates the crawl errors that occur when a site goes offline for maintenance. Note the limit, though: load balancing does nothing for a slow application. If each backend takes 900ms to generate a page, distributing requests across three of them still yields 900ms responses. Read more in What Is Time to First Byte (TTFB) and Why It Matters.