QUIC moves the routing decision out of the network header and into a label the endpoint chooses. For anyone running an HTTP/3 edge, that single change rewrites how a load balancer picks a backend, how state survives a client moving between networks, and what your dashboards can still tell you. The sections below cover the mechanism, the wire format, and the traps that show up in production.

The four-tuple breaks at the edge

TCP load balancers have leaned on the five-tuple for two decades. Source address, destination address, source port, destination port, protocol. Hash that, and every packet in a flow lands on the same backend. It is cheap, it is stateless, and it stops working the moment the flow outlives the tuple.

QUIC connections are designed to outlive it. A phone that moves from Wi-Fi to cellular keeps its connection, and a NAT that rebinds a UDP mapping does not necessarily tear down the session. The client keeps talking, the addresses change, and a hash over the tuple now points at a different machine that has never seen this connection.

The failure mode is quiet. The balancer forwards packets to a backend with no matching state, the backend has nothing to decrypt the handshake with, and it either drops the traffic or sends a stateless reset. From the client's side the page stalls and retries. From the operator's side the error rate graph barely moves because the flow simply re-establishes somewhere else.

Connection IDs as the new routing key

QUIC gives each connection one or more connection IDs, usually shortened to CIDs. They are opaque to the network. RFC 9000 defines them as the field a receiver uses to look up connection state, and it explicitly allows an endpoint to issue several and to change which one it uses over the life of a connection.

That is the hook an edge can grab. Instead of hashing the addresses, the balancer reads the destination CID from the packet and consults a mapping it maintains: this CID belongs to backend pool B, on node 17. The client picks the bytes, so the balancer cannot assume structure, but it can assume the value is stable enough to route on.

No packet inspection is required beyond the first bytes of the UDP payload. The balancer does not need to terminate TLS, does not need the keys, and does not need to parse frames. It reads a length-prefixed identifier and forwards. That keeps the fast path cheap, which matters when the same box handles millions of short-lived requests.

Migration without dropping the handshake

When a client changes addresses, QUIC runs path validation before it trusts the new path. The endpoint sends a challenge on the new address and waits for the response, which confirms the peer can actually receive there. Until that completes, traffic may continue on the old path. The balancer has to tolerate both paths being live at once.

CID rotation is the harder coordination problem. A backend that issues a fresh CID mid-connection must publish that CID to whatever component makes routing decisions, and the publication has to happen before the client starts using it. Get the ordering wrong and packets arrive bearing a CID the balancer has never seen.

Backends therefore need a state store that is reachable from the routing layer, or the balancer needs a deterministic way to derive the backend from the CID itself. Encoding a backend identifier into the CID is the common trick, though it costs bits and leaks topology to anyone who looks. Fallback to TCP remains necessary regardless, because some networks still block UDP outright.

What actually changes at the wire

QUIC has two header forms. The long header, used during the handshake, carries the destination CID and source CID as explicit length-prefixed fields after the version. The short header, used for most data, omits the length field and puts the destination CID at a fixed offset determined by the negotiated length.

That asymmetry is the whole reason a balancer can be simple. It reads the first byte, checks the header form bit, and knows whether to skip a version field or jump straight to the CID. The negotiated CID length is a property of the listener, so the offset is known per pool rather than per packet.

Orphaned connections need protection too. If a balancer routes a packet to a backend that has lost state, the backend replies with a stateless reset, a small packet carrying a token the client recognises. That token has to be generated from a key the whole pool shares, otherwise a reset from the wrong node looks like an attack and the client keeps retrying.

Operational traps in CID routing

CID collisions across tenants are the first surprise. Nothing in the protocol prevents two clients from choosing the same bytes, and if the routing table is global, one tenant's traffic can be steered into another's backend. Scoping the mapping by listener or by an anycast prefix avoids it, at the cost of more table entries.

Idle timeouts race with rotation. A connection that goes quiet for longer than the balancer's mapping TTL loses its entry while the client still considers it open. The next packet triggers a lookup miss and a reset. Setting the mapping TTL comfortably above the negotiated idle timeout is the fix, and it means the balancer needs to know that timeout.

Health checks have to speak QUIC. A TCP connect to the UDP port proves nothing, and an HTTP/2 probe against a listener that only serves HTTP/3 will fail every time. Observability degrades as well: the five-tuple that used to identify a flow in logs is no longer stable, so CID-to-backend mappings become the join key for tracing. A related piece on status list fetch discipline makes a similar point about state that quietly expires.

Deploying CID routing in practice

Audit what your backends actually store per connection. If session state lives only in process memory, CID routing will strand it the first time a node restarts, and you need an external store or a rehandshake path before you turn the feature on.

Instrument the CID-to-backend mapping as a first-class metric. Count lookup misses, reset emissions, and mapping table size per pool. Misses are the leading indicator of rotation ordering bugs, and they show up long before users report stalls.

Test migration with synthetic rebinding. Bring up a client, complete the handshake, then change its source address mid-stream and watch whether the connection survives and whether the balancer keeps routing to the same node. Do this in staging with the same CID length you run in production.

Roll out per listener rather than globally. One pool, one CID length, one mapping table, observed for a week. Keep the TCP fallback path warm and monitored throughout, because a meaningful share of clients will still land there and a cold fallback path is its own outage.

Encoding topology into the CID

Many edge fleets take the shortcut of embedding a backend identifier directly into the CID bytes. The balancer then derives the backend by masking and shifting, with no mapping table at all. That removes the lookup miss class of bugs entirely and makes the fast path a few ALU ops. The trade-off is that the CID length must accommodate the identifier plus whatever randomness the client expects, and the identifier is visible on the wire to anyone who can observe the connection. Rotating a backend out of service means waiting for every connection carrying its identifier to drain or rotate, which can take longer than the mapping-table approach where an entry can be rewritten.

A middle path is to keep a small, per-node mapping table and encode only a node index in the CID. The table stays tiny and cache-friendly, and the index can be remapped to a different physical node during maintenance without changing the CID the client sees. This is the approach I would start with on a new deployment, because it keeps the fast path predictable while leaving room to move connections around.

Keeping TCP fallback warm

Every HTTP/3 deployment needs a TCP path, and the balancer has to treat it as a first-class citizen rather than a legacy afterthought. The fallback listener should share the same backend pool and the same health-check semantics, but it will hash on the five-tuple because that is all it has. That means two routing models running side by side, and the metrics have to distinguish them or you will misread the dashboards. A sudden drop in QUIC traffic with a matching rise in TCP is a signal that something on the UDP path broke, not that clients suddenly prefer TCP. Alert on the ratio, not the absolute counts.