Правильная реализация - отдельный независимый демон (сервер) обслуживающий websocket (есть как модуль к веб серверу так и отдельные приложения, ка я понял модули не взлетели, т.е. кто то где то использует но массово нет), этот же демон анализирует базу данных или какие то другие локальные для сервера вещи и передает данные на клиент.
Кстати не обязательно переписывать весь проект на новую архитектуру, можно по частям, сначала вот эта часть, уведомляющая об каких то изменениях реализуется рядом в виде сервиса, затем опросы базы данных подменяются колбеками между основным бакэнждом и этим сервисом (пусть временно через те же http запросы) но потом постепенно приложение может переехать полностью в эту часть.
Самое верное, реализовать свое приложение не как http rest архитектура (где каждый запрос это запуск приложения которое собирает заново свое состояние из базы данных или других мест) а как приложение и есть веб сервер, где между разными запросами оно не закрывается а значит память не очищается и состояние приложения остается постоянным. В этом случае http и websocket запросы будут идти к одному и тому же приложению, а если все изменения в данных происходят через веб, то нет нужды даже периодически перечитывать базу данных, ведь момент изменения нужных данных можно отловить и в этот же момент инициировать отсылку нужным клиентам данных.
Этот подход наиболее эффективный по всем параметрам, на порядок или даже два быстрее чем http rest (с оговорками, существуют способы ускорить его за счет рядя ограничений и нагромождений на стороне сервера), эффективный по памяти, меньше нагрузка на базу данных и прочее прочее, за счет того что все приложение крутится в пределах буквально одного приложения (некоторые даже в пределах одного потока остаются, используя асинхронные методы работы с файлами, базой, сетью).
К сожалению недостаток напрямую вытекает из этого свойства - масштабировать такое приложение тяжело. Если http rest масштабируется чуть ли не из коробки, даже почти не затрагивая приложение только со стороны администрирования продукта (накидываешь серверов, реплики базы, кеши и т.п.) то тут придется сильно менять приложение и подгонять его к работе в кластере.
Единственное скажу что 'эти проблемы' у подхода начинаются с десятков и сотен тысяч пользователей.