Executei a resposta do @leomarciano com o GOLDEN MEDAL pro Cloudflare Durable Objects. Não cheguei nas 300 mil conexões. E o que me barrou não foi socket, nem CPU, nem mensagem por segundo. Foi um await. Implementei o que ele listou como "TODAS AS FUNÇÕES NORMAIS DE UM CHAT": rate limit, ban check, moderação síncrona e assíncrona, slow mode, spam, persistência em lote, presence, ranking, delete retroativo. O QUE PASSOU 400 espectadores, 40 remetentes, 5 minutos no topo, sala com 8 shards: ack p99: 232ms (limite 250) entrega fim a fim p99: 344ms (limite 1s) handshakes perdidos: 0 de 400 mensagem confirmada e não entregue: 0 de 3.602 presença vs sockets abertos: 0,25% de divergência 6 critérios, 6 PASS. A RESSALVA, E ELA VALE PRO POST INTEIRO Isso é uma PoC de algumas horas, não um benchmark. A carga saiu de uma máquina só, do meu ambiente local, contra o deploy real. Um teste completo nesse volume pede uma frota: mais ou menos uma VM a cada 10 mil sockets, porque uma máquina esbarra na faixa de portas efêmeras muito antes de o chat esbarrar em qualquer coisa. Talvez eu suba essa frota num segundo momento. Aqui o objetivo era validar a hipótese, e ela foi validada até onde uma máquina alcança. O que já foi longe o bastante pra derrubar duas suposições minhas. O QUE EU TINHA ERRADO NA CABEÇA Eu achava que a latência vinha de sockets por shard, e que era só dividir mais. Medi, com as mesmas 1.000 conexões: 8 shards, 126 sockets cada → ack p99 601ms 20 shards, 53 sockets cada → ack p99 922ms Menos sockets por shard e a latência piorou 53%. Não era nada do que eu esperava ver. Fui olhar o código: o RoomCoordinator chama todos os shards no fanout e espera todos. A duração de uma rodada é o máximo entre eles, e o máximo de 20 amostras tende a ser pior que o de 8. Cada shard a mais é mais uma chance de a sala inteira esperar pelo mais lento. POR QUE ISSO ME TRAVOU EM 300K 300 mil sockets precisam de pelo menos 60 shards pra caberem no teto de 5.000 por shard. Mas 20 shards já estavam piores que 8. Ou seja, o desenho que eu fiz tem uma contradição interna: preciso de muitos shards pra segurar os sockets, e muitos shards deixam o coordinator lento. E o await é literal: o coordinator soma o "delivered" de cada shard pra devolver um PublishResult que o shard descarta. Ele se bloqueia no resultado de um trabalho que ninguém lê. É corrigível, só não está corrigido. RESPONDENDO DIRETO A escada de teste de carga tem um degrau exatamente no seu número: 200 mil conexões com 35 mil remetentes. Esse degrau pede 20 VMs gerando carga, e eu rodei tudo de uma máquina só. Então ele está no repo marcado como NÃO RODADO, junto com o procedimento pra quem quiser executar. Inclusive eu, num segundo momento. Nenhum número aqui é extrapolado. Se um degrau não foi executado, ele aparece como não executado. Na thread: o que me custou latência e o que não custou, o botão de config que cortou o ack pela metade sem deploy, a conta de egress e o que eu consegui apurar de custo. 🧵