L4 vs L7 Load Balancers

Load balancers operate at different layers of the OSI network model, and the layer at which they operate fundamentally determines their capabilities, performance characteristics, and appropriate use cases. L4 (Layer 4, transport layer) and L7 (Layer 7, application layer) load balancers are not competing technologies -- they are complementary, and most large-scale architectures use both in a tiered configuration. Understanding the trade-offs between them is essential for designing systems that balance performance with routing intelligence.

L4 load balancers operate at the transport layer, making routing decisions based on TCP or UDP packet headers: source IP, destination IP, source port, and destination port. They do not inspect the payload, decrypt TLS, or parse HTTP headers. This simplicity is their strength: without the overhead of content inspection, L4 load balancers can handle millions of connections per second and tens of gigabits of throughput on modest hardware. L4 load balancers route traffic using two primary mechanisms. NAT (Network Address Translation) rewrites the destination IP of incoming packets to the selected backend server, and the return traffic flows back through the load balancer for reverse NAT. DSR (Direct Server Return) rewrites only the inbound packet's destination MAC address, allowing the backend server to respond directly to the client without routing return traffic through the load balancer. DSR is critical for bandwidth-heavy workloads like video streaming, where return traffic (the actual video) is orders of magnitude larger than request traffic.

L7 load balancers operate at the application layer, fully understanding the protocol being load balanced (typically HTTP/HTTPS). They terminate TLS connections (decrypting at the load balancer), parse HTTP headers and URLs, inspect cookies, and make intelligent routing decisions based on request content. An L7 load balancer can route /api/* requests to API servers and /static/* requests to a CDN origin. It can read a session cookie to provide sticky sessions without IP-based hashing. It can add, modify, or remove HTTP headers (X-Forwarded-For, X-Request-ID). It can enforce rate limiting, integrate with a WAF (Web Application Firewall), compress responses, and cache static content. This intelligence comes at a cost: TLS termination, HTTP parsing, and content inspection require significantly more CPU than L4 packet forwarding, resulting in 10-100x lower throughput per instance.

The standard production architecture at scale uses L4 in front of L7. A tier of L4 load balancers (Linux IPVS, Google Maglev, AWS NLB) distributes TCP connections across a pool of L7 load balancers (Nginx, Envoy, HAProxy). The L4 tier handles raw connection distribution at wire speed using consistent hashing (ensuring the same TCP connection always reaches the same L7 instance), while the L7 tier provides intelligent HTTP routing, TLS termination, and request-level features. This separation of concerns allows the L4 tier to scale to millions of connections per second (it just forwards packets) while the L7 tier can be scaled independently to handle HTTP parsing and application logic. Google's architecture exemplifies this: Maglev (L4) distributes across GFE (Google Front End, L7) instances, which perform TLS termination, protocol negotiation (HTTP/2, HTTP/3), and route to backend services.

An L4 load balancer is like a traffic controller at an airport entrance who routes cars to different parking garages based on their license plate number (IP address). The controller does not know what the passengers are carrying -- just where their car should go. Very fast, handles many cars per minute. An L7 load balancer is like the security checkpoint inside the terminal: it opens every bag (decrypts TLS), reads boarding passes (HTTP headers), checks passports (authentication), and directs passengers to the correct gate (backend server) based on their destination. Much slower per passenger, but makes intelligent routing decisions based on content.