mysql — PHP & amp; Угловой 2 — «живой» прямой обмен сообщениями с собственным API и базой данных

Я «много» исследовал приложения для живого чата и еще много чего, но я не смог найти недостающую часть или направление, в котором я должен идти.

Что я ищу
Частная система прямого обмена сообщениями между двумя пользователями без отправки запросов на выборку через фиксированные интервалы.

Что у нас уже есть.
Полный PHP Rest API с MySQL для всего нашего приложения, включая пользователей, сообщения, сообщения, профили и т. Д., И целое клиентское приложение Angular 5.

Текущая система обмена сообщениями работает на основе базовых процедур POST для отправки сообщений и GET для получения новых сообщений (каждые 30 секунд) (тогда никогда не было целью создания приложения для чата в реальном времени)

В отношении базы данных и API существуют «диалоги» между двумя идентификаторами UserID, и каждый диалог содержит сообщения с UserID-from.

Найденные предложения:

• Сокеты (через Socket.io или что-то в этом роде): «проблема» заключается в том, что к концу лета мы, по крайней мере, стремимся к более чем 10 тысячам пользователей. Сокеты, вероятно, разрушат наш сервер или, по крайней мере, наш PHP API, если будет более 500 открытых сокетов, или я ошибаюсь? (наша текущая ситуация с GET, вероятно, также ..)

• Firebase: Но у него есть своя отдельная база данных и все такое, и мы не уверены, как объединить это с нашим существующим API, аутентификацией и прочим.

• Более 100 тем и ситуаций, которые похожи на приложение для чата, а не на обмен сообщениями между двумя зарегистрированными пользователями.

У меня также была идея создать отдельный микро-сервис для части обмена сообщениями, основанный на сервере NodeJS Express, но с другой стороны, клиентам потребуется открытый сокет для этого сервера, а не просто «сокет», а частный канал. только для этих двух пользователей? (И тогда мне пришлось бы использовать некоторые грязные части nodejs-mysql для идентификаторов пользователей и аутентификации вместо того, чтобы запускать все, например, в Mongo)

На данный момент … Я не уверен, в каком направлении идти и как это реализовать, не имея необходимости «передавать» наши данные сообщений стороннему серверу, например, Firebase, или тратить драгоценное время, пытаясь использовать 4-5 различных методов. ,

Я знаю, что мне, вероятно, придется переписать всю часть обмена сообщениями о клиентских приложениях, но это меньше всего меня беспокоит.

В каком направлении мне идти и с какими мыслями? Может быть, кто-то в такой же ситуации, что и для преобразования существующего приложения datababse-разговор-users-stuffs?