Если описать базу мессенджера двумя таблицами users и messages, самая трудная часть системы останется за кадром. Кто имеет право читать чат? Как адресовать данные конкретному устройству? Чем сообщение отличается от подтверждения его доставки? Где заканчивается пользовательская переписка и начинается управление инфраструктурой?

В ZionVox я использую схему данных как карту этих ответственностей. После пути сообщения из Z03 разберу не отдельный запрос, а связи, которые делают этот путь допустимым.

В backend/src/models/index.ts User связан с Chat через chat_participants. При этом у Chat отдельно существует ownerId, а у Message — senderId. Эти связи похожи только внешне: владелец управляет ресурсом, участник входит в его состав, отправитель создал конкретное сообщение.

В chat.model.ts определены private, group, secret и channel. isPublic хранится отдельно. Там же есть publicHandle, теги и secretTtlHours. Такое разделение не позволяет незаметно отождествить «группа» и «публичный ресурс».

Аккаунт может иметь несколько устройств. Поэтому Device связан с User, а SyncDelta отдельно ссылается на sourceDeviceId и targetDeviceId. Направление синхронизации записано явно: кто создал дельту и кому она предназначена.

Message — основная сущность сообщения. MessageRelayIndex помогает резервному контуру находить данные по хешу ciphertext/iv. В message.model.ts индекс пополняется после создания непубличной записи; ошибка обрабатывается отдельно, а в server.ts предусмотрено восстановительное заполнение.

В index.ts видны PreAccount, ReentryAudit, SnapshotEvent и SnapshotStateAccount. Это отдельный предметный контур: идентичности, подтверждения и материализованное состояние управления. Он не сводится к специальному тексту в пользовательском чате.

Из belongsTo можно понять направление связи. Но этим нельзя доказать набор реальных индексов, CHECK-ограничений и поведение конкурентных вставок в развёрнутом PostgreSQL. Для этого нужны определения таблиц, SQL и проверка порядка применения изменений.

В полной статье — последовательность операций, разбор отказов и практический чек-лист. Я проектирую такие архитектуры и для клиентских продуктов.

https://arhellist.ru/blog/baza-messendzhera-bolshe-chem-users-i-messages/