What is the difference between an L4 (transport-layer) and an L7 (application-layer) load balancer, and what routing or scaling decisions can an L7 balancer make that an L4 balancer cannot?

## Where the labels come from The 'L4' and 'L7' labels come from the OSI networking model: layer 4 is the transport layer (TCP/UDP), and layer 7 is the application layer (HTTP, gRPC, etc.). ## What an L4 balancer can see An L4 load balancer makes its routing decision using only information available at the transport layer, without ever looking inside the packet payload: - source IP, - destination IP, - source port, - destination port, - and protocol. Mechanically, this is often implemented as connection-level forwarding or even NAT/DSR (direct server return): the balancer picks a backend for a new TCP connection (or, for UDP, a flow) based on a hash of the connection tuple, and then simply relays packets back and forth, or in DSR setups, only handles the inbound direction while the backend replies directly to the client. Because it never parses the payload, an L4 balancer is **protocol-agnostic** - it works identically for HTTP, a database wire protocol, a custom TCP service, or arbitrary UDP traffic - and it is very fast, since forwarding packets is cheap compared to parsing them. ## What an L7 balancer unlocks An L7 load balancer sits one layer higher: it actually terminates the client's connection (including TLS, if used), reads the parsed application-layer request, and only then decides which backend should handle it, typically opening a separate connection to that backend (or reusing one from a pool). Because it understands the protocol, it can inspect the HTTP method, URL path, query string, headers, and cookies, and route on any of them. This unlocks capabilities an L4 balancer simply cannot offer: - **path-based routing**, where requests to `/api/orders/*` go to an orders microservice and `/static/*` go to a CDN-backed static file service, all sharing one public hostname; - **header- or cookie-based routing**, used for canary releases (route 5% of requests carrying a beta cookie to the new version) or A/B testing; - **content-based rewriting** and redirect rules; - **cookie-based session affinity**, where the balancer injects a cookie identifying which backend handled the first request and pins subsequent requests from that client to the same backend. L7 balancers can also do things like request retries and circuit breaking on 5xx responses, since they can actually see the response status, something an L4 balancer cannot do because it never decodes the payload. ## What that capability costs The cost of that capability is real. Terminating a connection means the L7 balancer must do a full TLS handshake with the client (unless TLS passthrough is used, which sacrifices most L7 features), buffer and parse the HTTP request line and headers, and then originate a fresh connection (or reuse a pooled one) to the chosen backend - effectively doubling the number of TCP connections in play and adding CPU work for parsing and, if applicable, TLS. This adds latency, typically low single-digit milliseconds for a well-tuned proxy but nontrivial under very high request rates, and it means the L7 balancer itself becomes a more resource-intensive piece of infrastructure that needs its own capacity planning. It also means the L7 balancer sits directly in the data path for every request rather than just the initial connection setup, so bugs or misconfiguration in it (a bad routing rule, an overloaded proxy process) can break traffic in a much more visible, protocol-aware way, such as returning malformed 502s instead of silently dropped packets. ## Why production layers both Because of this trade-off, production architectures very often layer both. - A cloud **Network Load Balancer** (a pure L4 device, such as AWS's NLB) sits at the outermost edge because it can handle extremely high packet-per-second throughput with minimal latency and survives volumetric attacks well, and it forwards traffic to a tier of L7 balancers or reverse proxies (an AWS ALB, NGINX, HAProxy in HTTP mode, or an Envoy/Istio service mesh sidecar) that do the smart, content-aware routing to individual microservices. - **Kubernetes Ingress controllers** are a familiar concrete example of L7 balancing: the Ingress resource defines path- and host-based routing rules ('/orders goes to the orders-service, /users goes to the user-service'), and the underlying controller (NGINX Ingress, Envoy-based Contour, etc.) implements them by terminating HTTP and dispatching per request. ## The rule of thumb A good rule of thumb when choosing: if you just need to spread raw TCP/UDP load across identical backends serving the same thing, L4 is simpler, cheaper, and faster; the moment routing needs to depend on what's inside the request - the URL, a header, a cookie, the response code - you need L7.