L4 vs. L7 load balancing — what's the actual difference in what they can see and do?

#Same goal, different vantage point

Both a Layer 4 and a Layer 7 load balancer answer the same question — "which backend should handle this connection?" — but they answer it from completely different vantage points in the network stack, and that difference in vantage point is the entire interview question. L4 operates at the transport layer: it sees IP addresses, TCP/UDP ports, and packet or connection-level metadata. L7 operates at the application layer: it terminates the connection, decrypts TLS if present, and actually parses the protocol riding on top — HTTP method, path, headers, cookies, even the body.

#What an L4 load balancer can and can't do

An L4 load balancer makes its routing decision using only what's in the IP and TCP/UDP headers: source and destination IP, source and destination port, and protocol. It does not decrypt TLS, does not parse HTTP, and generally forwards packets (or maintains a lightweight connection table) without ever understanding what's inside them. This makes it extremely fast and cheap in CPU terms — there's no parsing, no TLS handshake termination — which is why L4 balancing is common for high-throughput, protocol-agnostic workloads: raw TCP services, database connection pooling, or as the outer layer in front of an L7 balancer.

Its limitation is exactly its strength: because it can't see into the payload, it cannot route `/api/users` to one pool and `/static/` to another, cannot inspect a cookie to keep a user pinned to a server, cannot make a decision based on a request header, and cannot terminate TLS on your behalf.

#What an L7 load balancer can and can't do

An L7 load balancer terminates the client's connection — including the TLS handshake — and reads the actual application-layer request before deciding where it goes. Because it understands HTTP (or gRPC, or WebSockets), it can do content-based routing (send `/api/` to the API fleet, `/images/` to a static asset service), inspect and rewrite headers, implement retries and circuit breaking per backend, do canary releases by routing a percentage of traffic based on a header, and terminate TLS once at the edge so your backends don't each need to manage certificates.

The cost is exactly what you'd expect: terminating TLS and parsing HTTP is CPU work that L4 doesn't do, and it opens a second connection to the chosen backend (client-to-LB and LB-to-backend are two separate TCP connections), which adds a small amount of latency and means the backend sees the load balancer's IP as the source unless you propagate the real client IP via a header like `X-Forwarded-For`.

#Where each shows up in practice

L4 load balancers are the right tool when the protocol isn't HTTP at all (raw TCP database traffic, custom binary protocols), when you need the absolute lowest latency and CPU overhead, or when TLS termination needs to happen at the backend itself for compliance reasons (pass-through TLS). L7 load balancers are the right tool anywhere you need routing logic that depends on the content of the request — which is most modern web and API traffic, and virtually all microservice ingress.

#Comparing what each layer can see and act on

🧠 Check your understanding
0/2 · 0/2 answered
1. An L4 load balancer is sitting in front of a fleet of HTTPS backends using TLS pass-through. Why can't it route requests based on URL path?
L4 load balancers do not support HTTPS traffic at allIt never decrypts the TLS payload, so it never sees the HTTP method, path, or headers inside itURL paths are only assigned after the TCP handshake completesL4 load balancers only work with UDP
2. What is the main latency/CPU trade-off of choosing an L7 load balancer over an L4 one?
L7 balancers cannot handle as many concurrent connectionsThere is no meaningful trade-off, L7 is strictly betterL7 load balancers require a dedicated GPUL7 terminates TLS and parses the application protocol, then opens a second connection to the backend, both of which cost more CPU and add a small amount of latency versus L4's simple packet forwarding