Load-test connections and fanout

Start from the behavior you can observe. One incident sent to ten thousand quiet viewers creates different pressure from ten thousand operators sending commands.

Live systems often fail from connection count and fanout shape rather than ordinary request throughput. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to benchmark a single fast local client and extrapolate from it. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to test representative connection lifetimes, message sizes, fanout, slow clients, and synchronized recovery events. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Ship a live feature that has limits, useful telemetry, a degradation path, and a repeatable failure test matrix. Record enough evidence that another developer can repeat the result without relying on your memory.

Run a staged load test and record the first resource that becomes limiting rather than chasing a vanity connection number. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.