Layer 4 versus Layer 7 load balancer comparison

Networking & Traffic Management

The Balancer That Reads Your Request and the One That Refuses To

The layer number is a statement about how much of your request the balancer is willing to read — and everything else follows from that one choice. A Layer 4 balancer works at the transport layer: it sees source address, destination address and ports, and nothing inside. It picks a backend once, when the connection opens, and every byte of every request on that connection goes to the same machine. A Layer 7 balancer terminates the connection, parses the HTTP, and routes per request — which is why it can split one client connection across many backends, and why it has to hold the plaintext and own your certificates.

Key Components

L4 · Transport

Picks once per connection

Reads only the TCP 5-tuple. Chooses a backend when the connection opens; has no idea where one request ends and the next begins.

L7 · Application

Picks per request

Terminates TLS, parses HTTP. Sees method, path, host header and cookies — so one keep-alive connection can fan out to several pools.

Cost ledger

L7 pays for sight

Holds plaintext → owns your certificates, buffers and re-serialises, adds latency and memory. L4 just rewrites addresses — fast and cheap.

The trap

Client IP is not free

Once a proxy hop exists, the real client IP is off the wire. L7 restores it by adding a header the backend must be configured to trust.

How It Works

Client opens one TCP connection. L4 looks at source/dst IP + ports only; L7 would also see what TLS wraps.

L4: pick once, forward everything. One backend for the life of the connection. It can forward encrypted traffic it cannot read — that is exactly why it is cheap.

L7: terminate, parse, decide per request. The same client connection can send /images to one pool and /checkout to another.

L7 can retry what it understands. A failed request is just a unit it knows how to re-send on another backend. L4 cannot retry a request it cannot see.

The honest test: send two different paths down one keep-alive connection and log which backend served each. Both on the same machine → you have L4, whatever the console calls it.

Belief to break: “L7 is newer and better, L4 is legacy.” Both are current. Ask what the balancer must read to make the decision you want — if the answer is “nothing, just spread connections,” L7 buys you cost and a certificate to rotate for no routing benefit. And no: L7 does not make a balancer an API gateway.

Real-World Applications

Where L4 is the right answer

Database connections (Postgres, Redis)
Message brokers (Kafka, AMQP)
Game servers, any long-lived stream
Raw throughput where per-request routing is meaningless

Where L7 earns its cost

Route by path, host header or cookie
Retry failed requests on healthy backends
Canary deploys and per-route rules
TLS termination — one cert, not one per backend

Checkpoint — answer before you move on

You send two different paths down a single keep-alive connection and both are served by the same backend. What layer is the balancer actually running at — and why is that the decisive observation?
Name two things a Layer 7 balancer must do that a Layer 4 balancer never does, and the two costs that fall directly out of them.
After a proxy hop, the client IP is no longer on the wire. How does a Layer 7 backend recover it, and what must the backend be configured to do for that to be safe?