PlayInfoBox

Home /Education /What Is Load Balancing? The Basics Explained

What Is Load Balancing? The Basics Explained

Here is why a website can absorb a sudden traffic spike without going down, and how a load balancer actually decides where each request goes.

What load balancing is

Load balancing spreads incoming traffic across multiple servers instead of sending it all to one, so a single overloaded or failed server does not take the whole service down. A load balancer sits in front of a pool of servers, accepts every request, and routes each one to whichever server is best suited to handle it at that moment.

Round robin

The simplest and most common method: incoming requests are handed to servers in strict rotating order, server A, then B, then C, then back to A. It is easy to implement and works well when every server has similar capacity, but it ignores the fact that some servers may already be busier than others.

Least connections

Instead of rotating blindly, this method sends each new request to whichever server currently has the fewest active connections, in other words, the least busy one. It produces a more even distribution than round robin when request processing times vary a lot, such as when some requests involve a slow file upload.

IP hash (session persistence)

This method always routes a given client's requests to the same server, based on a hash of the client's IP address. It matters for services that store session data, like login state, in one server's memory rather than sharing it, since without IP hashing a user could get logged out simply because a later request landed on a different server. The trade-off is that many users behind the same shared IP, such as an office network, can end up piling onto one server.

Layer 4 vs. Layer 7 load balancers

A Layer 4 load balancer only looks at network-level information, IP addresses and ports, so it is fast but limited to simple routing rules. A Layer 7 load balancer inspects the actual request content, such as the URL path or browser type, and can route '/images' traffic one way and '/api' traffic another. That makes it especially useful for microservice architectures split by function.

Health checks

A load balancer periodically pings each server, or calls a dedicated status-check URL, to confirm it is responding normally. If a server stops responding or keeps erroring out, it is automatically and temporarily pulled from the pool so users never see its failures, then added back once it recovers. A good health-check URL tests something meaningful, such as whether the application can reach its database, rather than merely returning a fixed 'OK'.

Load balancers vs. CDNs

A load balancer distributes traffic among servers that usually sit in the same data center; a content delivery network (CDN) distributes traffic across edge servers spread around the world. Large-scale services typically use both together: a CDN routes a request to the nearest region first, and a load balancer then splits it among the servers within that region.

Load balancing plus autoscaling

In cloud environments, a traffic surge can trigger autoscaling to automatically launch new server instances, which the load balancer immediately starts routing traffic to. When traffic drops, unneeded instances are scaled back down to save cost, so the two systems are commonly paired in cloud infrastructure.

Sticky sessions with cookies

Instead of hashing the IP address, many Layer 7 balancers insert a cookie that records which server handled the first request and send later requests from that browser to the same server. This avoids the shared-IP problem of IP hash, but it still ties users to one server, so if that server is removed the session is lost. The more robust design is to keep session data in a shared store such as a database or in-memory cache, so any server can serve any request.

TLS termination and the real client IP

Many load balancers handle HTTPS encryption themselves, a practice called TLS termination, and forward plain or re-encrypted traffic to the back-end servers. This offloads work and lets certificates be managed in one place. Because the back-end then sees the balancer's address as the source, balancers usually add the original address in a header such as X-Forwarded-For, which the application must be configured to trust only from the balancer.

Weights and connection draining

Servers in a pool are not always identical. Assigning weights lets a larger machine receive proportionally more traffic. When a server is taken out for maintenance or a deployment, connection draining stops sending it new requests but lets in-flight requests finish, so users are not cut off mid-action. Rolling updates, where servers are updated a few at a time, depend on this behavior.

Load balancing algorithms beyond the basics

Round robin and least connections are the two most common starting points, but production systems often use refinements on top of them: weighted round robin, giving more powerful servers a larger share of requests, least response time, factoring in how quickly a server has been answering recently, and consistent hashing, used heavily in caching layers so the same key almost always maps to the same server even as servers are added or removed.

Load balancing in modern, cloud-native infrastructure

Beyond a single dedicated appliance, load balancing today often happens at several layers at once: a cloud provider's managed load balancer in front of the whole application, an ingress controller distributing traffic inside a Kubernetes cluster, and a service mesh handling load balancing between individual internal services. Each layer solves the same basic problem, not overloading any one instance, at a different scope.

What a load balancer cannot fix

A balancer spreads work, but it does not make a slow application fast. If every server shares one overloaded database, adding more web servers behind a balancer moves the bottleneck rather than removing it. Likewise, a balancer in front of servers that keep state locally can break logins or shopping carts. Before adding servers, find the real bottleneck with monitoring, and make the application stateless where possible.

A simple request walk-through

A visitor opens the site and their browser resolves the domain name to the balancer's address. The balancer accepts the connection, picks a healthy server using its algorithm, and forwards the request. The server builds the response, which returns through the balancer to the visitor. If that server had failed its last few health checks, the balancer would have skipped it, and the visitor would never know. Metrics such as requests per second per server, error rate, and response time are what operators watch to confirm the distribution is healthy.

Frequently Asked Questions

What happens if the load balancer itself fails?

To avoid the load balancer becoming a single point of failure, real-world deployments usually run at least two load balancers in an active-standby or active-active setup, so if one goes down the other keeps handling traffic without interruption.

Does a small website need load balancing?

Not if a single server comfortably handles its traffic. Once traffic grows enough to require multiple servers, though, a load balancer becomes essential, since there is no other way to split incoming requests across them.

Is a load balancer the same as a reverse proxy?

They overlap. A reverse proxy sits in front of servers and forwards client requests to them, and many reverse proxies can also balance load. A Layer 7 load balancer is essentially a reverse proxy with distribution and health-check features, while a Layer 4 balancer works at a lower level without reading the request.

Which algorithm should I choose?

Round robin is a sensible default for similar servers and short requests. Choose least connections when request durations vary widely, weighted variants when servers differ in size, and hashing or cookies only when you must keep users on the same server.

Can a load balancer protect against attacks?

It can absorb some traffic and hide back-end addresses, and many managed balancers add rate limiting or a web application firewall, but a balancer alone is not a complete defense against large denial-of-service attacks.