История изменений

Я уже порядком забыл о чем тут речь была, какой-то некропостинг.

Но замечу что, «магистральные коннекты» (это ты так назвал репликацию видимо), какой-то непонятный set который хранится в виде b-tree (таких готовых БД не существует кажись), заставлять сервер хранить стейт клиента, отдельный микросервис (наверное спроектирован по DDD) для лайков, и вообще архитектура которую ты тут описываешь это сложная и дорогая дичь, по сравнению с тем что предложил я - просто хранить список сообщений, линейный, без всяких сетов, и когда кто-то ставит реакцию - всем в чатике уходит новое сообщение с реакцией и id сообщения к которому она относится. Когда появялется новое сообщение любого типа - клиент просто получит новое сообщеие, куда бы он ни был подключен (ну да, прям как наверное в https://nanochat.ru).

Ну да, тут есть минус - нельзя будет просто взять из базы рандомное сообщение и за O(1) увидеть его лайки (не сканируя все следующие сообщения в чате, я имею в виду).

О боже. Какой ужас, это же то, ради чего создаются чаты. Чтобы что - только я не смог придумать.

Если идти по моему пути то нужна одна любая база данных, (No)SQL, с репликацией, и/или шардированием, и в первом приближении все. При чем на диск запросы записи будут последовательные, что было-бы еще одним аргументом «за» 10 лет назад.

По твоему пути будет нужна база с синхронной репликацией, кастомными типами данных, которые будут позволять хранить зачем-то огромные set в виде дерева на диске, реплицировать состояние клиента ( и решать конфликты, когда вдруг окажется, что соединения протухают не мгновенно). И да, установка лайка приведет к рандомному чтению с диска (что было-бы минусом 10 лет назад).

В обоих случаях еще нужна какая-то система нотификации что новое сообщение появилось, но это успешно решается уже редисом например, с pub/sub.

Но вообще твое решение будет наверное ок, пока живет на одном сервере и без «магистральных» коннектов.

Я уже порядком забыл о чем тут речь была, какой-то некропостинг.

Но замечу что, «магистральные коннекты» (это ты так назвал репликацию видимо), какой-то непонятный set который хранится в виде b-tree (таких готовых БД не существует кажись), заставлять сервер хранить стейт клиента, и вообще архитектура которую ты тут описываешь это сложная и дорогая дичь, по сравнению с тем что предложил я - просто хранить список сообщений, линейный, без всяких сетов, и когда кто-то ставит реакцию - всем в чатике уходит новое сообщение с реакцией и id сообщения к которому она относится. Когда появялется новое сообщение любого типа - клиент просто получит новое сообщеие, куда бы он ни был подключен (ну да, прям как наверное в https://nanochat.ru).

Ну да, тут есть минус - нельзя будет просто взять из базы рандомное сообщение и за O(1) увидеть его лайки (не сканируя все следующие сообщения в чате, я имею в виду).

О боже. Какой ужас, это же то, ради чего создаются чаты. Чтобы что - только я не смог придумать.

Если идти по моему пути то нужна одна любая база данных, (No)SQL, с репликацией, и/или шардированием, и в первом приближении все. При чем на диск запросы записи будут последовательные, что было-бы еще одним аргументом «за» 10 лет назад.

По твоему пути будет нужна база с синхронной репликацией, кастомными типами данных, которые будут позволять хранить зачем-то огромные set в виде дерева на диске, реплицировать состояние клиента ( и решать конфликты, когда вдруг окажется, что соединения протухают не мгновенно). И да, установка лайка приведет к рандомному чтению с диска (что было-бы минусом 10 лет назад).

В обоих случаях еще нужна какая-то система нотификации что новое сообщение появилось, но это успешно решается уже редисом например, с pub/sub.

Но вообще твое решение будет наверное ок, пока живет на одном сервере и без «магистральных» коннектов.