Load balancer internals — L4 vs L7

In 1996, a startup called Alteon Networks shipped the first hardware load balancer that could inspect HTTP request content and route based on the URL path. Before Alteon, load balancing meant DNS round-robin or the first-generation NetScaler box that just forwarded TCP packets based on source-IP hashing. Alteon's trick was to open the TCP payload, parse the HTTP request line, and route /api/* to the API pool while sending /images/* to a CDN origin. The distinction became so fundamental that engineers today still describe load balancers as "Layer 4" or "Layer 7" — using the OSI model as the naming convention.

The distinction is not academic. It determines everything about how your load balancer behaves — what it can route on, what it sees, whether it decrypts TLS, whether it can do canary rollouts, whether it works for non-HTTP protocols like MySQL or Redis, and how it survives DDoS attacks. Confusing L4 with L7 in an interview signals "I know how to configure AWS ALB but haven't debugged a real packet trace." Knowing the difference cold signals systems fluency.

The modern landscape is polymorphic: AWS NLB is pure L4, AWS ALB is pure L7, Envoy and Nginx can operate as either based on configuration, Cloudflare deploys L4 anycast for DDoS scrubbing followed by L7 WAF at the edge PoPs, and Cilium uses eBPF to blur the line entirely by running L4 forwarding decisions in the Linux kernel while making L7 metadata available. Every real system does both. Knowing which layer solves which problem is the goal of this deep-dive.

The core mental model — what each layer SEES

Every packet crossing a load balancer contains layers of headers, wrapped like an onion. Whether the LB peels each layer or forwards the packet as an opaque blob defines its class.

┌─────────────────────────────────────────────┐
│  L2 Ethernet header  (MAC addresses)         │  ← visible
├─────────────────────────────────────────────┤
│  L3 IP header  (src IP, dst IP, TTL)         │  ← visible
├─────────────────────────────────────────────┤
│  L4 TCP header  (src port, dst port, flags)  │  ← visible ← ROUTES HERE
├─────────────────────────────────────────────┤
│  ▓▓▓▓ ENCRYPTED TCP PAYLOAD ▓▓▓▓             │  ← opaque
│  ▓▓▓▓ (never opened by L4 LB)   ▓▓▓▓         │
└─────────────────────────────────────────────┘

Routing decisions based on: destination port,
source IP hash, TCP flags, connection state.
L4 has NO IDEA what protocol runs inside.

The question every candidate asks — "If L4 doesn't know it's HTTP, how does it route?"

This is the most common source of confusion. L4 has no idea what "GET" or "/api" is. So how does an L4 load balancer make routing decisions? Answer: it uses only what's in the TCP + IP headers — and that's enough for most workloads.

1. Destination port — packets on port 443 → HTTPS pool; port 3306 → MySQL pool; port 6379 → Redis pool. One LB, many backend pools.
2. Source IP — hash-mod-N to a backend, giving sticky sessions. Same client → same server (until the pool changes).
3. TCP flags — SYN means a new connection: pick a backend. Existing connection: forward to the same backend (via connection tracking table).
4. Round-robin or least-connections — no client state at all. Just pick the least-loaded backend for each new SYN.

The L4 LB opens the SYN packet, decides on a backend, records "this source-IP:src-port ↔ backend" in its connection table, then blindly forwards every subsequent packet on that TCP connection. It never looks at the TCP payload. This makes L4 forwarding fast (kernel-level, ~5μs per packet) and protocol-agnostic (works for SSH, MySQL, gRPC, WebSockets, custom TCP — anything).

Eight scenarios — pick a workload, see which layer wins

The theory is clear. The practical test is: given a specific workload, which layer does the routing? Click through these to see how L4 or L7 handles each:

What L4 can do that L7 cannot

What L7 can do that L4 cannot

Product landscape — who does what

Modern hybrid — Cloudflare + Cilium blur the line

Real-world large-scale deployments almost always run both layers in series. The current gold-standard pattern:

1. L4 anycast at the edge — Cloudflare, Google Cloud, AWS Global Accelerator announce the same IP from hundreds of PoPs. BGP routes each client to their nearest PoP. First-line DDoS scrubbing here (SYN flood filtering, source-IP rate limits) drops 99% of malicious traffic before it enters the LB fleet.
2. L7 at the PoP or origin — TLS terminated, HTTP parsed, WAF applied, path-based routing to correct origin, cache lookup, rate limits per API key. This is where feature intelligence lives.
3. Backend service mesh — Istio, Linkerd, or Cilium sidecar-inject L7 proxies next to every service pod. mTLS terminates inside the mesh. Fine-grained per-service policy at the pod level.

Cilium's eBPF approach is the interesting outlier: because eBPF programs run in the Linux kernel, Cilium can make L4 forwarding decisions with L7 metadata as context without paying the userspace-copy cost. It's effectively "L4 speed with L7 awareness" — a genuinely new point on the trade-off curve enabled by kernel programmability.

Real-world deployments

Interview cheat sheet

Key takeaways

1. L4 = connection-level routing. Uses only IP + TCP headers. Protocol-agnostic. Fast (kernel-speed). Blind to HTTP content.
2. L7 = request-level routing. Parses HTTP. Can inspect path, headers, cookies, body. Slower per request (userspace + buffering) but massively richer feature set.
3. L4 answers "where should this connection go?" ONCE per connection. L7 answers "where should this request go?" per request — many per connection with HTTP/2.
4. Modern deployments run BOTH. L4 at anycast edges for DDoS scrubbing, L7 at PoP or origin for feature routing. Cilium blurs the line via eBPF.
5. Choose L4 for: non-HTTP protocols, encrypted passthrough, extreme PPS, DDoS scrubbing, UDP + QUIC.
6. Choose L7 for: path routing, canary rollouts, WAF, HTTP compression, header manipulation, application health checks, HTTP/2+HTTP/3 termination.