Здесь, имхо, вопрос предпочтений - когда есть асинхронный контекст - для меня это всегда какая либо очередь/топик сообщений. БД это pooling. А дальше уже вопрос предпочтений. Реализовать можно и так и так

и я не думаю что тут есть единственно правильное решение :)

Ну, в очереди проблема, что много очередей большинство MQ не умеет.
А в БД можно их сделать (как и собственно очереди).

Никто не мешает завести отдельного воркера, который будет заниматься исключительно обработкой уведомлений, в отдельном контейнере. У нас так сделаны schedule-таски.

Пуллинг по БД - штука не такая уж и сложная или дорогая

Кстати, не самое хорошее решение для scheduled-задач.

Тем не менее, тот же sidekiq рубишный на первый взгляд является именно чем-то таким. Пишет в крон, чекает таски.

А много и не надо. Достаточно просто очередь с нотификациями для всех кто подключен к этому ws-серверу.

Я бы постарался вообще не смотреть про решения на руби )

Ага. А как ты будешь распределять пользователей по разным ws-серверам? И что делать при перегрузке этого сервера?

Я про такую схему думал, там не очень все прямо получается (

А в чем проблема? И что подразумевается под "перегрузка"?

У меня есть Python - тяп ляп и готово, есть Rust если нужна минимальная задержка. Так как есть и задачи отчётного типа, и задачи реалтайма, то... То на самом деле раст смысла не имеет. Он работает слишком быстро, у нас фронт дольше обрабатывает и соединения делает. Вариант in-db выглядит не слишком тормозным (postgres писали умные люди) и достаточно простым, чтобы в пару сотен строк уместить реально весь процессинг, не считая кода самого вебсокета.

Сотка проца и "оооой, что-то даже ssh лагает", думаю

Основная проблема - что воркеров на таски должно быть много (иначе одна долгая задача тормозит вообще всех).
Тогда при получении задач эти воркеры не должны мешать друг другу, а это уже только через все тот же skip locked.

Да не, просто выключили сервис при обновлении версии )

Я думаю, с этим столкнусь уже при реализации. Сейчас пока сложно представить, как именно должны распределяться воркеры и кто за что отвечает.

Условно как будет с вашей реализацией:
Ряд эндпоинтов кроме своей непосредственной работы загоняет сообщение в очередь, мол, добавилось X, оповести Y типа Z(группа, юзер, не важно) видом уведомления V
При подключении к сокету сокет добавляет себя в хешмапу и отдаётся на откуп воркеру, который раз в N вейкается (у нас же holy async можем себе позволить слипы) и чекает очередь + другие таблицы, чтобы если там что-то появилось, например, скоро подходит срок, добавить это тоже в очередь. Как только он разберётся и выделит актуальные записи, начнётся проходка по мапе с рассылкой нужных сообщений по нужным группам. Тот же сокет может ожидать сообщения "read", на которое воркер легитимно удалит прочитанное из очереди.

Единственное вопрос - собственно, а как такой воркер выглядеть должен? :)
Звучит как внешний демон, с которым мы *как-то* общаемся. Либо что-то во внутреннем коде, которое крутится в while true и по вейку читает новую инфу из глобальных переменных. Например, те же присланные read можно тупо в список класть, как и хешмапа с сокетами, и pop'ать все.

" например, скоро подходит срок, добавить это тоже в очередь." - лучше сразу запланированное событие добавлять в очередь, зачем это делать отдельно и потом?

"который раз в N вейкается" - стандартный хинт "если в очереди пусто - то ждем. Если что-то нашли, то сразу попробуем взять событие еще"

Если добавлять к существующему сервису, очередь как минимум нужно создать из существующих данных. Делать это отдельной миграцией?

Насчёт скоро подходит срок это я наверное да. В голове почему-то не сошлось что сущности сами себя уже положили в очередь