Skip to content

PATTERN Cited by 1 source

Connection pooling amortizes handshake cost

Pattern

When a proxy or gateway sits between many clients and a smaller set of backend servers, fan-in connection pooling reuses a small number of persistent connections to each backend. This amortizes per-connection setup cost (TLS handshake, authentication, TCP slow start) across many requests.

Why it matters for post-quantum

Post-quantum signature algorithms like ML-DSA have significantly larger key/signature sizes than classical (1.3 kB pubkey + 2.4 kB signature for ML-DSA-44, vs 32 B + 64 B for Ed25519). In a naive per-request-connection model, this overhead is paid on every request. With connection pooling, it's paid once per connection establishment and amortized across the thousands of requests that reuse that connection.

Cloudflare explicitly names this as the reason they could deploy "drop-in" PQ signatures on the Cloudflare→origin connection without needing Merkle Tree Certificates (which batch and amortize differently):

"This gives us the control to employ techniques such as connection pooling to fan in requests from all over our network to a smaller set of connections to origin servers, amortizing the overhead of connection setup over many requests. This makes the cost of 'drop-in' post-quantum signatures more palatable, and the performance benefits of MTC less necessary."

(Source: sources/2026-07-29-cloudflare-post-quantum-authentication-to-origins)

Canonical instance

Pingora Origin (35 M req/sec on ~40,000 CPU cores) fans in all origin-bound requests through pooled connections, making ML-DSA's larger handshake materials a one-time amortized cost rather than a per-request tax.

Seen in

Last updated · 602 distilled / 1,824 read