Load Balancer Fundamentals: L4 vs L7
L4 is fast, protocol-agnostic, and content-blind; L7 routes on content and terminates TLS at a CPU cost; production stacks L4 at the edge in front of an L7 fleet, all made HA.
Stacking L4 and L7, the production shape
Level 1's "Load Balancing: L4 vs L7 & Health Checks" lesson introduced the two layers. This lesson credits that and goes to the shape real systems actually run: an L4 tier stacked in front of an L7 fleet. A one-paragraph refresher first, because the layer choice still decides your routing features and throughput.
L4 (transport-layer) balancers work at TCP/UDP, see only IP and port, and forward packets without parsing the payload, so they are fast, protocol-agnostic (raw TCP, database connections, WebSockets), and content-blind: no path routing, no TLS termination, no rate limiting (AWS NLB, Google Maglev, IPVS). L7 (application-layer) balancers terminate the connection, parse HTTP/gRPC, and route on content (path, host header, cookie, method), which also unlocks TLS termination, rate limiting, request/response transformation, and rich per-route observability, at a higher per-request CPU and latency cost (AWS ALB, Nginx, HAProxy, Envoy).
You are picking a balancer feature by feature. Which layer does each one need?
Stack them
Real architectures stack the layers: a thin L4 layer at the edge absorbs the raw connection volume and spreads it across a fleet of L7 proxies behind it, which do the smart routing. The canonical shapes are NLB in front of ALB on AWS, or Maglev in front of Envoy at Google. The L4 layer gives you cheap, protocol-agnostic scale and DDoS surface; the L7 layer gives you features.
Stage 1 of 3: The L4 edge sees only IP and port and forwards packets without parsing the payload, so it absorbs the raw connection volume: fast, protocol-agnostic, and content-blind.
The LB tier itself must be HA
Whichever layer you run, the LB cannot be a SPOF: if all traffic funnels through one box and it dies, you are down regardless of fleet health. Make the tier HA with active-active nodes plus a failover mechanism, either a floating/virtual IP (keepalived/VRRP) or anycast so many nodes share one IP and BGP routes around a dead one. Cloud LBs bake this in.
Interview nuance: a common trap is choosing L4 for an HTTP API and then discovering you need path-based routing or TLS termination, which L4 cannot do. If the question mentions per-path routing, header-based canaries, or TLS termination, you need L7 somewhere. Conversely, if it is raw non-HTTP traffic or extreme throughput with minimal features, L4 alone is right.
Recap: L4 balancers are fast, protocol-agnostic, and content-blind; L7 balancers parse requests to route by path/header, terminate TLS, and rate-limit at a latency cost; production stacks L4 at the edge in front of an L7 fleet, and the LB tier itself must be made HA (active-active, floating IP, or anycast) so it is never a SPOF.
Apply
Your turn
The task this lesson builds to.
Choose and justify the load-balancing layers for a service handling both gRPC APIs and long-lived WebSocket connections.
Think about
- What does L4 give in throughput vs what L7 gives in routing features?
- Why do real architectures stack L4 in front of L7?
- How is the LB itself made highly available?
Practice
Make it stick
A second problem on the same idea, so it survives past today.
Choose the load-balancing layers for Cloudflare-scale edge traffic terminating tens of millions of concurrent TLS connections across hundreds of PoPs, where a single PoP or LB node failure must not drop the service, and justify where TLS terminates.
Think about
- What does consistent hashing at the L4 tier protect during L7 fleet changes?
- Why terminate TLS at the PoP rather than at origin?
- How does a whole-PoP failure disappear without a DNS change?