What does a load balancer do, and what is the difference between L4 and L7 load balancing?
A load balancer sits in front of a group of servers and spreads incoming requests across the healthy ones, so no single server is overloaded and failures are hidden from users. An L4 balancer routes by IP address and port without reading the request. An L7 balancer reads HTTP details such as path, host and headers and can route on them.
Explain it simply
Think of a big bank branch with eight cashier counters. At the door stands a token machine with an attendant. You do not pick a counter yourself; the attendant sends you to one that is free. If a cashier goes on a break, the attendant stops sending people to that counter.
That attendant is a load balancer. Customers only see one entrance. Behind it, the bank can add or remove counters without anyone outside noticing.
Now the two types. An L4 attendant looks only at your token number and sends you on. Fast, but knows nothing about why you came. An L7 attendant asks "deposit, loan or locker?" and sends you to the right section. Slightly slower, but much smarter.
Example
Users -> api.example.in -> Load balancer
|
L7 rules: |
/api/payments/* -> payment servers (3)
/api/search/* -> search servers (5)
everything else -> web servers (4)
Health check every 10s: GET /health
web-2 stops responding -> removed from rotation
web-2 recovers -> added backAn L4 balancer in the same spot would just forward TCP connections on port 443 to any server in one pool, without looking at the path.
How it works
What a load balancer gives you
- Distribution: spreads load so each server works at a sensible level.
- Health checks: pings servers and sends traffic only to healthy ones.
- One stable address: clients talk to one name; servers can change behind it.
- TLS termination: decrypts HTTPS once at the balancer so servers do less work (L7).
- Easier deployments: drain one server, update it, put it back.
L4 vs L7
| L4 (transport) | L7 (application) | |
|---|---|---|
| Looks at | IP, port, protocol (TCP/UDP) | HTTP method, path, host, headers, cookies |
| Speed | Very fast, low overhead | More work per request |
| Routing | Same pool for a port | By URL, domain, header; can rewrite or redirect |
| Typical use | Databases, game servers, any TCP/UDP | Web apps, APIs, microservices |
Common algorithms
- Round robin: next server in turn. Simple, good when servers and requests are similar.
- Weighted round robin: bigger servers get a larger share.
- Least connections: send to the server with the fewest active connections. Good when requests take uneven time.
- IP hash / consistent hashing: the same client or key always goes to the same server, useful for caches.
- Random with two choices: pick two servers at random and use the less busy one; simple and surprisingly effective.
Real-world use
On AWS, an Application Load Balancer is L7 and a Network Load Balancer is L4; Nginx and HAProxy can do both. Large Indian apps handling a flash sale put an L7 balancer in front of each service so a surge on search does not starve checkout. DNS-based balancing across regions often sits above all of this.
Common mistakes
- Forgetting that the load balancer itself can fail. Production setups run it redundantly or use a managed service.
- Relying on sticky sessions to hide that the app stores state locally. If that server dies, the user's session dies too.
- Health checks that only check "process is running" rather than "can serve a request".
- Using round robin when some requests take 10 ms and others take 10 seconds.
What to say in the interview
"A load balancer sits between clients and a pool of servers. It spreads requests across healthy servers using health checks, gives clients a single stable endpoint and lets me add, remove or update servers without downtime. L4 balancing works on IP and port, so it's fast and protocol-agnostic. L7 understands HTTP, so it can route by path or host, terminate TLS and add headers. For algorithms I'd start with round robin, use least connections when request times vary, and consistent hashing when the same key should hit the same server. The balancer must itself be redundant."
Follow-up questions
- How does a load balancer know a server is unhealthy?
- What are sticky sessions and why can they be a problem?
- How would you load balance across two data centres?
- What is the difference between a load balancer and a reverse proxy?
Go deeper
Read these once the basics above feel easy.
Connection draining lets a server being removed finish in-flight requests before it stops receiving traffic. L7 balancers usually add an X-Forwarded-For header so the app sees the real client IP. With HTTP/2 or long-lived WebSocket connections, a balanced spread of connections does not mean a balanced spread of work, so least-connections or periodic reconnects help.
Global traffic management combines DNS (geo or latency-based routing) or anycast with regional load balancers. Inside large systems, client-side load balancing in a service mesh (each service picks a healthy instance itself) avoids an extra hop. Watch for retry storms: when a server slows, aggressive retries through the balancer can multiply load, so use timeouts, retry budgets and backoff.