Types of Load Balancers: L4 vs. L7
Why this matters: this single choice determines whether your load balancer can route on a URL, terminate TLS, and rate limit — or whether it just moves packets very fast. It is the most common load balancer question in interviews.
Key takeaway
Load balancing can be performed at different layers of the OSI model. Layer 4 operates at the transport layer and moves connections. Layer 7 operates at the application layer and understands requests. L7 is smarter about content; L4 is faster due to lower processing overhead.
Layer 4 load balancers
L4 load balancers operate at the transport layer (TCP/UDP). They maintain connection sessions and ensure that packets from the same connection reach the same backend server — which is essential, because a TCP connection split across two servers is simply broken.
They are typically content-agnostic: they see IP addresses and ports, not what the request says. Some L4 load balancers do support TLS termination.
The decision is made once per connection, then every packet follows the same path. That is why it is fast — there is almost nothing to compute after the first packet.
Layer 7 load balancers
L7 load balancers operate at the application layer. They inspect HTTP headers, URLs, cookies, and other data to make intelligent routing decisions. They also handle TLS termination, rate limiting, and header rewriting.
Because it understands the request, it can send different requests on the same connection to different backends — something an L4 load balancer fundamentally cannot do.
The comparison
| Aspect | Layer 4 | Layer 7 |
|---|---|---|
| OSI layer | Transport (TCP/UDP) | Application (HTTP) |
| Can see | IP addresses, ports | URLs, headers, cookies, body |
| Routing granularity | Per connection | Per request |
| Speed | Faster — lower processing overhead | Slower — must parse the request |
| Content-based routing | ||
| TLS termination | Some support it | |
| Rate limiting, header rewriting | ||
| Protocol support | Anything over TCP/UDP | HTTP and similar application protocols |
What each one unlocks
| Capability | Requires | Why |
|---|---|---|
| Route /api and /video to different fleets | L7 | Needs to read the URL path |
| Canary 5% of traffic by header | L7 | Needs to inspect headers |
| Terminate TLS to offload backends | L7 (or L4 with support) | Must handle the handshake |
| Rate limit per API key | L7 | The key is in the request |
| Balance a non-HTTP protocol | L4 | L7 only understands application protocols it can parse |
| Maximum throughput, minimum latency | L4 | No parsing on the data path |
| Preserve the client's source IP end to end | L4 | L7 proxies terminate the connection and re-originate it |
The answer is usually "both"
These are not competing choices at the system level — they occupy different positions in the same stack. A common arrangement puts a fast L4 tier in front of a smart L7 tier:
The L4 tier absorbs enormous connection volume cheaply and spreads it across L7 instances; the L7 tier does the expensive, intelligent work on a manageable share each. That is exactly the structure the next lesson formalizes as tier-2 and tier-3.
Key takeaway
Choose L4 when you need raw speed, non-HTTP protocols, or the original source IP. Choose L7 when routing depends on what the request says. At scale, layer them — L4 in front for volume, L7 behind it for intelligence.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Layer 4 works on TCP, layer 7 on HTTP." |
| L5 | Picks for a reason: "we need path-based routing to split /api from /video, so it has to be L7 — and it can terminate TLS while it's there." |
| Staff+ | Layers them and handles the fallout: "L4 in front for cheap connection distribution, L7 behind it for content routing and TLS. And terminating TLS means re-encrypting to the backend unless we're happy with plaintext inside the perimeter." |
Next: how these tiers are actually deployed in a real data center.