Как спроектировать storage для real-time чата?

Проектирование хранилища для чата в реальном времени — это задача, требующая баланса между производительностью, надёжностью и удобством разработки. Основная нагрузка приходится на операции записи (отправка сообщений) и чтения (получение истории, подписка на новые сообщения).

Ключевые сущности и схема данных

Минимальный набор сущностей включает:

• Пользователи (users): id, имя, аватар, статус онлайн/офлайн.
• Чаты/беседы (conversations): id, тип (личный, групповой), название, дата создания.
• Участники (participants): связь пользователя с чатом (user_id, conversation_id, роль).
• Сообщения (messages): ядро системы. Поля: id, conversation_id, sender_id, текст, timestamp, статус доставки/прочтения.

Выбор технологий и архитектура

Для обработки потока сообщений в реальном времени часто используют комбинированный подход:

• In-memory хранилище (Redis): идеально для кэширования сессий, онлайн-статусов, непрочитанных сообщений и последних N сообщений активного чата для быстрого доступа.
• Основная база данных (PostgreSQL или MongoDB): для долговременного хранения всей истории сообщений. PostgreSQL с JSONB полями даёт гибкость, а MongoDB удобна для схемы, которая может эволюционировать.
• Шардирование/партиционирование: таблицу сообщений можно партиционировать по conversation_id или дате, чтобы распределить нагрузку и ускорить запросы к истории конкретного чата.

Пример схемы таблицы сообщений в PostgreSQL

CREATE TABLE messages (
    id BIGSERIAL PRIMARY KEY,
    conversation_id UUID NOT NULL,
    sender_id UUID NOT NULL,
    content TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    -- Индексы для быстрого поиска
    CONSTRAINT fk_conversation FOREIGN KEY(conversation_id) REFERENCES conversations(id),
    CONSTRAINT fk_sender FOREIGN KEY(sender_id) REFERENCES users(id)
);

CREATE INDEX idx_messages_conversation_created ON messages(conversation_id, created_at DESC);

Поток данных и оптимизации

При отправке сообщения оно сначала записывается в основную БД, затем его копия может помещаться в Redis-кэш для активных чатов, а также отправляется через WebSocket или SSE подключения всем онлайн-участникам. Для загрузки истории делается запрос к основной БД с пагинацией (LIMIT/OFFSET или ключом на created_at).

Вывод: Такое хранилище стоит применять для чат-приложений, где важна мгновенная доставка сообщений и быстрый доступ к истории. Комбинация Redis и PostgreSQL позволяет эффективно масштабироваться под растущее число пользователей и сообщений.