"Как только он разберётся и выделит актуальные записи, начнётся проходка по мапе с рассылкой нужных сообщений по нужным группам" - да сразу "прочитали событие - добавили в мапу, пометили как отправленное, пошли за следующим"
Можно добавить событие "timeout - если пришли и событие не read - сделать что-нибудь"

Ну да, отдельной миграцией, делов-то.

Миграции - это вообще главный инструмент при разработке )

"Либо что-то во внутреннем коде, которое крутится в while true и по вейку читает новую инфу из глобальных переменных. Например, те же присланные read можно тупо в список класть, как и хешмапа с сокетами, и pop'ать все."
Тред с бесконечным циклом, "прочитал - положил в мапу сокета - пометил - пошел дальше"

На отвал по хартбиту можно тоже что-то сделать в принципе. Это автоматически значит, что всё всё ещё unread и требует присылки на следующий connect

Балансировщиков на вкус и цвет много. Клиент просто сделает реконнект и все будет ок.

Это работает, если у тебя только один сервер с ws-ами.
Если несколько, то балансировка и подписка на правильные сообщения - уже не очевидна

Могут, конечно, все читать из топика, а "если у меня такого пользователя нет - то и пофиг".

Но тогда если пользователя нет - то его события улетят в никуда

Кстати, не знаю, уместно ли тут будет задавать такой вопрос, ибо выше идёт диалог о уведомлениях, но я в качестве дипломной/просто фан-проекта планировал сделать что-то типа лоад балансера как у aws/яндекса, но который автоматически покупает и вводит в эксплуатацию сервера vps-типа, притом у разных провайдеров, перераспределяя нагрузку на них.
Есть ли уже существующие такие инструменты или всё поглотили SaaS и куберы?

Это вопрос роутинга. Если мы знаем на каком ws-сервере находится клиент - всё относительно просто.

На самом деле, просто хочется разобраться с анализом нагрузки на железо/сервис и API облачных провайдеров в качестве автоматизации развёртки серверов, но интересно, нужны ли кому-то такие инструменты в реальности.

Угу, но как это узнать. Ну не sticky-session же реализовывать, в конце концов.

Я не слишком верю в интеллектуальный роутинг, он обычно дает больше проблем, чем решений )

В протокольчике, что поверх ws сделать. Как в мобильных сетях с location update.

Так не спасет, это же у тебя очередь должна знать, какой сервис обрабатывает клиент и отдавать нотификации на него.
ws-у тут пофиг

Ну и по хорошему для клиента все сервера должны быть одинаковыми, что один, что десять. Он просто цепляется на entrypoint и получает события.

Клиент ничего не знает про сервера :)

Тогда чем тебе поможет протокол поверх ws?
Вот у тебя очередь с сообщениями, вот читающие из нее сервера с ws.
Как серверу с ws понять, что ему делать с сообщением для пользователя A - отправить в сокет, вернуть в очередь или игнорировать (так как это для другого сервера)

У каждого сервера ws свой топик, а роутинг между топиками по in-memory табличке.