A load balancer sits in front of your servers and spreads incoming requests across them. It's what makes horizontal scaling possible and keeps the system available when individual servers fail.
What a load balancer does
- Distributes traffic so no single server is overwhelmed.
- Removes unhealthy servers from rotation (via health checks).
- Provides a single entry point and can terminate SSL.
- Enables zero-downtime deploys by draining servers gracefully.
Common balancing algorithms
- Round robin — send each request to the next server in turn. Simple and even.
- Least connections — send to the server with the fewest active connections. Good when requests vary in cost.
- Least response time — factor in latency as well.
- IP / consistent hashing — route a given client to the same server (useful for sticky sessions or cache locality). See consistent hashing.
Layer 4 vs Layer 7
Layer 4 load balancers route on IP and port (TCP/UDP) — very fast, but they can't see the request content. Layer 7 load balancers understand HTTP, so they can route by URL path, headers or cookies (e.g., send /api to one pool and /images to another) at the cost of more processing.
Health checks and redundancy
The load balancer regularly pings each server; if one fails, it stops routing to it. The load balancer itself must not be a single point of failure — run it in an active-passive or active-active pair with a floating IP.
Frequently Asked Questions
What is the difference between Layer 4 and Layer 7 load balancing?
Layer 4 routes based on IP and port without inspecting the request, making it very fast. Layer 7 understands HTTP and can route by URL, headers or cookies, enabling smarter routing at higher cost.
Is the load balancer a single point of failure?
It can be, so production setups run at least two load balancers in active-passive or active-active mode with a shared/floating IP so traffic keeps flowing if one fails.