The formula and its one calculation

The core relation is short: cores per node must be at least R_storm divided by the product of c_core, (N minus one) and u. Here R_storm is the reconnect rate when a node fails, c_core is the number of full hybrid handshakes one core sustains, N is the pool size and u is the utilisation ceiling your latency target allows. Take an estimated storm of 40,000 handshakes per second, roughly the sessions held by one node arriving back inside a few seconds of client retry jitter, and an estimated c_core of 4,000 X25519MLKEM768 handshakes per second including the certificate signature. That gives an estimated 10 cores of pure handshake work. In a two-node active/active pair, N minus one is one, so the surviving node needs all 10 estimated cores free before u is even applied, and steady-state traffic has to fit on top of that. Each extra node splits the requirement, which is why the third node is usually cheaper than the extra headroom a pair would need on its own.

Where the error bars come from

Treat c_core as good to a factor of two at best, because it depends heavily on what each handshake actually computes. ML-KEM-768 encapsulation and decapsulation are cheap compared with the certificate signature, so the signature algorithm and key size set most of c_core, and an ML-DSA migration on the authentication side will move it more than the key exchange does. R_storm is even less certain. It comes from client retry policy, connection-tracking timeouts on upstream load balancers and how fast health checks drain the dead node, and none of these are under the gateway team's control. The defensible approach is to measure c_core on the target silicon with real certificate chains and to treat R_storm as a range taken from a fault injection test, not a vendor datasheet.

The failure that doubles the bill

The case that actually breaks pools is an accelerator failure, not a node failure: when a lookaside crypto card or its driver drops out, the gateway silently falls back to the software path, c_core falls to whatever general-purpose cores can manage, and a node that looked like it had headroom becomes the next one to tip over, which sets off a cascade. The IETF hybrid key-agreement work for TLS 1.3, HPKE with its combined dual-PRF derivation, and PSK-augmented WireGuard ingress all make the same choice here. Correctness never depends on the accelerator, so a fallback always succeeds, only slower. That makes a software-path c_core measurement mandatory, because it is the number that holds during the worst minute of the year. WireGuard ingress adds a further effect: under load its cookie mechanism adds a round trip to each handshake. This protects the responder but lengthens the storm, so R_storm drops while its duration grows.

The decision rule follows from all of the above: size so that N minus one nodes running the software fallback absorb R_storm below u, then cut R_storm itself by sharing session ticket keys across the pool, so that clients reconnecting to a survivor run a PSK resumption with a fresh hybrid key share, which skips the signature without giving up post-quantum forward secrecy. The cost is that a ticket key shared across the pool is now a secret every node holds, and its rotation schedule becomes part of your failure domain.