Вот мне тоже интересен кейс - зачем такое?

за "бакет" в 250 мс

1. Каскад точно нужен.
2. Лучше UDP, ws такое себе для этой цели.
3. Можно считать в пределах ноды среднее и потом в одно место скидывать, где будет аггрегат по всем нодам. Не обязательно считать прям все данные в одном месте, цифра получится +- та же самая. Downstream будет иметь по 1 соединению с каждой upstream ноды.
4. Имплементация по желанию конечно, но стандартный стек на tcp + nodejs будет уныло медленным. С WS вообще будет больно в любом случае.

кейс для стриминговой индустрии развлечений

Не скажу надо пробовать, я делаю агрегацию за день и неделю, сумму и количество событий

Походу должно подучится

как с UDP посчитать количество соединений? пришло например 500 пакетов с флоат значениями от 0 до 1, это может быть 500 клиентов по 1 пакету в секунду а может быть 50 яростных клиентов по 10  пакетов в секунду. Это разный уровень интенсива итогового числа. первое - ну да, тепленькая реакция ,второе - ого фанаты лютуют

5. Балансер придется мутить свой и скорее всего на клиенте. Проксировать 10м соединений это даже больше хард лимита NLB в 2m.

Возможно nginx сможет положить в кафку…

Слать key:value userid:digit?

Ну и стабилизировать отправку на клиенте, чтобы он не слал почем зря.

и тайстамп я бы добавил, а то надеятся что сеть синхронна и без задержек и потерь шлет инфу

Я предполагал что он или там есть, или оно не так важно:)

Так то и клиент лагать может..

нет ограничения на то что там 1 инстанс, днс и раунд робин на 10-20 серверов, на каждом если по 1М - уже ок.

На каждом 1м это уже весьма нетрививально, хочу заметить)

Скорее всего без особого тюнинга получится 100-150к. Дальше уже оптимизации и магия. И весьма жирные машинки.

:) мы фантазируем. пока в DO верхний лимит 40к на самом большом load balancer, так что любые улучшения - хорошо