Load Balancing Explained: Layer 4 vs Layer 7
A load balancer distributes requests across servers so no single one gets overwhelmed. The interesting decision isn't "should I use one" — it's which layer of the OSI Model it operates at, because that choice has real consequences for speed, cost, and what it can actually do.
The quick answer
| Layer 4 (transport) | Layer 7 (application) | |
|---|---|---|
| Decides based on | IP address and port only | The actual request content |
| Speed | Fast — just forwards packets | Slower — has to parse the protocol |
| Protocol awareness | None needed | Has to understand the specific protocol |
| Can do | Simple, protocol-agnostic forwarding | Content-aware routing, sticky sessions, request inspection |
Layer 4: fast and protocol-agnostic
An L4 load balancer routes based on connection info alone — it doesn't need to know or care that the traffic is HTTP, or anything else. That makes it fast and simple, at the cost of not being able to make any decision based on what's actually inside the request.
Layer 7: reads the request, pays for it
An L7 load balancer terminates the connection and inspects the actual request before deciding where it goes. For HTTP, that means URL paths, headers, and cookies — enabling content-aware routing (/api/* to one pool, /static/* to another) and sticky sessions. The cost is real: more CPU work and higher latency per request, since the proxy has to actually parse the application-layer protocol.
L7 isn't only about HTTP
This is the part most explanations leave out. "Application layer" means whatever protocol is actually running — and a load balancer built to parse that protocol can make the same kind of smart decision on it:
- Databases — tools like ProxySQL (MySQL) and pgpool-II (PostgreSQL) read the query itself, routing
SELECTs to read replicas and writes to the primary. - Caches — protocol-aware proxies like Twemproxy understand Redis/Memcached well enough to shard keys consistently across a cluster.
- VoIP — SIP-aware proxies route calls by parsing the actual signaling protocol, not just IP and port.
Same tradeoff every time: understand more of the traffic, make a smarter routing decision, pay more CPU per request for it.
How it picks which server
Once a load balancer decides it's routing to a pool, it still needs a policy for which one — round robin, least connections, or consistent hashing (so the same client keeps hitting the same server, keeping that server's local cache warm). The algorithm matters as much as the layer.
Why this matters in an interview
Naming the layer and the algorithm — "an L7 load balancer with least-connections, since request durations vary a lot here" — is a specific engineering decision, not a generic "we'll add a load balancer." That specificity is what separates a real answer from a diagram with a box labeled "LB."
Go deeper
The full lesson has a health-check diagram, the full routing-algorithm comparison table, and diagrams for the database and cache examples above:
👉 Read the full Load Balancing lesson — part of the free System Design Lab course.