Рано или поздно вы решите написать чат. Да, свой чат. И, возможно, вспомните про эту статью.
Изложу свое понимание, видение на построение системы любого чата, будь то чат между 2 пользователями, групповой чат (открыто и закрытого типа), чат с контактом в другом мессенджере, канал, общение с посетителями сайта или пользователями приложения.
Все изложенное субъективно. Искал разные источники, анализировал другие чат-платформы. Надеюсь, будет полезно.
Итак.
Что такое чат? Мы каждый день общаемся в чатах, чаты в разных приложениях похожи и не похожи одновременно.
Сделаем несколько обобщающих утверждений, на которые будем опираться далее.
- Чат - это хронологическая лента сообщений.
- Сообщение - некая единица контента (текст, файл, картинка, аудио, видео, стикер, оповещение, ...)
- также у сообщения есть дата-время создания сообщения.
- У сообщения всегда есть отправитель.
- В чат сообщения могут добавлять разные отправители (пользователи, боты, система).
- В чате есть участники. По сути - это подписчики, которые подписаны на получение новых сообщений в чате.

Пожалуй, это база. Далее все просто немного расширяется и дополняется под каждый конкретный случай.
Таким образом, есть вопрос: а можно ли на этой базе построить какой-то относительно универсальный движок чата, который можно использовать для разработки любых систем чатов?
Попробуем.
Т.е. у нас в системе появляются такие сущности как Чат, Сообщение, Участник.
Также нам потребуются статусы сообщений - это ответ подписчика на полученное сообщение. Например, получил сообщение, прочитал сообщение.
Есть еще такой момент - системы разные и мы не знаем, какое поведение нам придется реализовать в каждом случае заранее.
Поэтому нам нужна гибкая система, где мы сможем навешать какие-то данные на наши сущности, и с ними в дальнейшем взаимодействовать.
Поэтому мы добавим мета теги - мета данные, которыми мы дополняем наш скелет системы чатов.
Далее поясню на примерах.
Для начала групповой чат - чат, в котором состоит несколько участников. Как обычно, если вы решили создать групповой чат - вы создали чат, как-то назвали его, добавили аватарку чата, добавили кого надо, отправили сообщение. Название чата и аватарка чата - это мета данные.
Например, вы строите систему чатов, где вам надо разделить видимость чатов и соответственно работу с ними - вводите мета данные - тип чата.
И у вас может быть групповой чат открытого типа - т.е. его можно найти в поиске и вступить, и у вас может быть чат закрытого типа -
не найти в общем поиске и добавление например только участником чата.
Как частный случай группового чата - чат p2p - это чат между двумя собеседниками. Но в этом случае мы не хотим какое-то название чата, типа "чат между Иваном и Сергеем".

Мы хотим название чата для Сергея - "Иван", а для Ивана - "Сергей". По сути в мета данных нам можно сохранить оба названия и при построении системы чатов использовать этот нюанс.
При этом процессы, которые нам необходимы для построения чата хоть на 100 подписчиков, хоть на 2-х - по сути одинаковы.
Например, мы решили в своей системе сделать чат типа "канал" - это когда в него могут писать только администраторы, а другие участники чата только читать.
Пожалуйста, навешивайте на участника чата мета тег role=administrator, и реализуйте, что с такой ролью могут писать, а без этой роли только читать.
Не знаю, получилось ли мне донести суть мета тегов? Напишите в комментариях.
Исходя из вышеописанных понятий, попробовал реализовать такой универсальный движок чата.
MMS3 - meta message server https://github.com/chottodev/mms3
В видео больше информации и примеров https://youtu.be/WmmEGqDUiRA, (там на 1,5 часа, выделены таймслоты примеров p2p, групповых чатов)
Поясню - это не готовая платформа чатов. Это основа для вашей платформы чатов. И это пока больше концепция, которую я проверяю.
На схеме отображено как это может быть реализовано. Т.е. вы берете mms3. А затем добавляете свой бекенд и фронтенд, где реализуете свои задумки по чату.
(По аналогии для node.js или python разработчиков, вы берете bullmq или celery, а не реализуете свое решение на базе redis или rabbitmq)

Под капотом используется mongodb для хранения данных сообщений и чатов, и rabbitmq для организации получения updates.
В MMS3 есть админка для просмотра данных, как если бы их получали по API.

Пару слов про updates.
Когда один из участников чата делает действие (отправляет сообщение, присылает статус, добавляет еще участника), т.е. происходит событие - то информацию об этом событии должны получить все остальные участники. Для этого есть update. MMS3 отправляет все updates в указанный exchange rabbitmq, и ваше приложение может создать очередь и забирать все необходимые updates (например, для websocket-сервера, который уже будет пушить update каждому пользователю онлайн)

Т.е. MMS3 берет на себя организацию чатов, сообщений, участников, статусов и updates. С помощью мета-тегов на чаты, сообщения, участников можно реализовать разные сценарии обработки на вашем бекенде. Например, чат-ботов и аналитику.
MMS3 - meta message server https://github.com/chottodev/mms3
пример приложения (из видео), использующее MMS3 https://github.com/antirek/chatapp
группа в тг chottodev https://t.me/chottodev
анализ от ИИ архитектур open-source проектов чатов https://github.com/antirek/chats-architecture
Интересны минусы или кейсы, которые сложно реализовать при таком подходе. Если есть соображения, пожалуйста, поделитесь. Или какие кейсы интересны, чтобы описать их реализацию на основе mms3. Например, с помощью мета-тегами можно обозначить закрепленые чаты, группы чатов (как папки в Телеграм), закрепленные сообщения в чате.
Комментарии (9)

Vvlad1973
19.12.2025 09:02Поддержу комментаторов. В чем ценность этой штуки по сравнению с обычным брокеров очередей, на который вы навешиваете свой функционал. Заявляя при этом, что тот же rabbitmq может быть сюда притянут? Только то, что можно добавлять мета-информацию и хранить историю? Ну ок, есть ещё какая-то валидации прав - все, или что-то ещё?

antirek Автор
19.12.2025 09:02да, вероятно, вы правы, не донес ценность этой штуки. сделав несколько систем обмена сообщениями, вынес общие элементы. и да, здесь хранение истории, добавление мета-информации к сущностям, события и updates. в общем, есть все чтобы быстро сделать любую достаточно сложную систему чатов. система фильтров для выборки по мета информации диалогов и сообщений - можно очень хорошо разделять разнотипные диалоги. мета информация участников - храним собственников чатов, роли участников. мета информация сообщений - легко выделить файлы, аудиосообщения. это обертка над бд и брокером сообщений, чтобы просто реализовывать свою бизнес логику, отделив работу с чатами и сообщениями. а еще админка, где все данные можно просмотреть и проверить свои запросы на эти данные.
gibson_dev
все бы ничего но доверия вашему (на самом деле AI) коду 0, после того как при добавлении юзера в диалог и юзер не найден происходит
process.exitantirek Автор
доверять коду? а как же "тысяча глаз"? )) поправим, напишите, пожалуйста, строчку, файл (можно здесь, можно в личку) - где косяк - и ИИ поправит. тут больше про верификацию концепта у меня запрос - "все бы ничего" - неплохо звучит
cupraer
Да не поправит ничего ваш ИИ. Для трех с половиной пользователей — это не интересно. Для трех хотя бы тысяч — проблемы не в отображении и какой-то мифической «платформе» — а в тех нюансах, которые ИИ неведомы, к сожалению.
А еще можно взять в качестве платформы просто голый rabbitmq и будет не хуже.
antirek Автор
Так назовите эти проблемы-нюансы )) Хей, "ИИ неведомы"... свое фи вы сказали. Можно и чистый rabbitmq взять, и на С написать, "..., но зачем?" когда можно и с подогревом, и со счетчиками, и с готовыми структурами, и будет не хуже
cupraer
За счетчики и готовые структуры либо придется платить накладными расходами, либо они уже есть в rabbitmq, разве нет?
antirek Автор
так, а в чем проблема?
cupraer
Нет никакой проблемы. Проблемы не существует. А вы ее решаете.