Layer 4 Load Balancing

Hop's redirect servers are all identical: any one of them can answer any short code. The load balancer in front of them does not need to understand anything about the request — it only needs to hand each new connection to some healthy server, very fast. That is exactly what a layer 4 load balancer does.

The rule

Layer 4 sees addresses and ports, never the request inside.

The "layers" come from the networking model. Layer 4 is the transport layer: TCP and UDP. At this level, a connection is described by a handful of numbers:

A layer 4 load balancer looks only at these, picks a back-end server, and forwards the whole connection there. It never reads the HTTP method, the URL path, headers or cookies — with HTTPS it could not read them anyway without decrypting.

What that gives you:

• Speed and scale — little work per packet, so it handles huge numbers of connections cheaply.
• Any protocol — works for HTTP, databases, game traffic, anything over TCP or UDP.
• Encryption untouched — HTTPS can pass straight through to the servers.

What it cannot do:

• route /api/ to one pool and / to another
• choose by cookie, header or user
• rewrite requests, add headers or cache responses

The shortcut

Ask: "Does the decision need anything inside the request?" No → layer 4 is enough, and it is the faster, simpler choice.

A subtle trap: because layer 4 balances connections, one browser keeping a connection open for many requests sends them all to the same server. With long-lived connections, load can end up less even than the request count suggests.

Drills

Answer fast — trust the rule.

Remember

• Layer 4 sees addresses and ports, never the request inside.
• Shortcut: if the decision needs nothing inside the request, layer 4 is enough and faster.
• Trap: it balances connections, so long-lived connections can skew the load.