layer-7 load balancing

Imagine two ways to sort incoming mail. A fast clerk could route each envelope using only the address on the outside — quick, but blind to what's inside. A slower, smarter clerk could open each envelope, read the letter, and route it by topic — to billing, to support, to sales. Layer-7 load balancing is the smarter clerk. It distributes requests by actually reading the application-layer content (the HTTP request itself), rather than just the transport-layer addresses and ports that layer-4 balancing uses.

Because it understands HTTP, a layer-7 balancer can make content-based routing decisions: send requests for /images/* to the image servers and /api/* to the API servers; route by the Host header so many sites share one balancer; keep a user on one backend by reading a session cookie; or split traffic for A/B tests. To do this it terminates the client's TCP (and TLS) connection, parses the request, then opens its own connection to the chosen backend — so it sits as a full intermediary and can also rewrite headers, compress, cache, and shield backends. Layer-4 balancing, by contrast, forwards whole connections by IP and port without inspecting them: faster and protocol-agnostic, but unable to route on URLs or cookies.

Why it matters: layer 7 is where most modern web load balancing happens, precisely because routing by application content is what microservices and multi-site hosting need. It is the same intelligence a reverse proxy and a CDN edge use to dispatch requests. The trade-off is honest: reading every request costs more CPU and a little latency than blind layer-4 forwarding, and terminating TLS means the balancer sees decrypted traffic, making it a trusted, security-sensitive point. Pick layer 4 when you need raw speed and protocol independence; pick layer 7 when you need to route by what the request actually says.