Раздел 1. Что такое мессенджер с точки зрения архитектуры

Это вводный раздел: здесь мы не лезем в протоколы и базы, а фиксируем одну мысль, из которой потом вырастают все остальные решения курса — мессенджер устроен принципиально не так, как обычный веб-сервис. Если эта мысль села, дальше всё ложится на неё. В главном тренажёре это та самая базовая схема, которую ты будешь дополнять по ходу курса.

Чем мессенджер отличается от модели «запрос — ответ»

Обычный сайт или веб-сервис живёт по схеме «запрос — ответ»: клиент что-то спрашивает, сервер отвечает, соединение закрывается. Открыл страницу — получил, и до следующего запроса сервер про тебя «забыл». Инициатива всегда у клиента.

Мессенджеру этого мало. Когда Алиса пишет Бобу, сообщение надо доставить тому, кто прямо сейчас ничего не спрашивает. Боб не опрашивает сервер каждую секунду «нет ли мне чего» — он может вообще смотреть в другое приложение. Значит, сервер должен уметь сам, по своей инициативе, толкнуть сообщение на устройство получателя. А чтобы было куда толкать, между устройством и сервером нужен заранее открытый канал — постоянное соединение (обычно WebSocket, подробно — Раздел 3).

Аналогия: обычный сайт — это справочное окно, к которому ты подходишь с вопросом. Мессенджер — это всегда поднятая телефонная линия: связь держат открытой, чтобы в любой момент можно было что-то сказать в обе стороны.

Вот это «доставить тому, кто не спрашивает» — и есть ядро отличия, ради которого вся архитектура и усложняется.

Ключевые сущности

Прежде чем рисовать, полезно назвать «действующих лиц» — на них держится вся модель:

• Пользователь (аккаунт) — это человек, его учётная запись.
• Устройство — телефон, ноутбук, веб-версия. Важно: аккаунт — это не одно устройство, у одного пользователя их обычно несколько, и каждое держит свою связь с сервером (Раздел 10).
• Чат — диалог (1-на-1) или группа/канал. Именно к чату привязан порядок сообщений (Раздел 6).
• Сообщение — единица переписки; у него есть уникальный номер, по которому ловят повторы и держат порядок (Раздел 6).

Различение «аккаунт ≠ устройство» кажется мелочью, но именно из него потом растут и мультидевайс, и сложности шифрования.

Хребет доставки

Главная схема всего курса — путь сообщения от отправителя к получателю. Запомни её как костяк, на который вешается всё остальное:

Клиент → балансировщик → сервер соединений отправителя → Message-сервис
        → (база сообщений + Реестр сессий) → сервер соединений получателя → клиент

У каждого узла одна понятная задача:

• балансировщик — принимает входящие соединения и ровно раскидывает их по серверам;
• сервер соединений (Conn-сервер, gateway) — держит живую связь с конкретным устройством;
• Message-сервис — «диспетчер», единая точка, через которую проходят все сообщения и где наводится порядок;
• база сообщений — надёжно хранит переписку;
• Реестр сессий — справочник «кто к какому серверу соединений сейчас подключён».

Никакой узел не «магия» — это и есть мысль, которую проговаривают на доске: ведут сообщение по цепочке, называя роль каждого шага.

Развилка онлайн / офлайн

Ключевой момент: сразу после того, как Message-сервис сохранил сообщение, происходит развилка.

• Получатель в сети: Реестр находит его активное соединение → сообщение доставляют сразу.
• Получатель офлайн: сообщение кладут в очередь ожидания, а устройство будит push-уведомление (APNs/FCM); при переподключении клиент сам забирает накопленное из очереди.

Главное, что стоит усвоить здесь и не путать дальше: онлайн и офлайн — это не два разных мира, а одна развилка, которая случается уже ПОСЛЕ сохранения. Сохранили — а дальше либо доставили сразу, либо положили в очередь. Детали — Разделы 4 и 5.

Что навешивается сверху

Базовый скелет доставляет текст между двумя людьми. Всё остальное — это навесные подсистемы, и каждая из них — отдельная инженерная задача со своими нагрузками и компромиссами. Поэтому их и выносят отдельно, а не пихают в одно ядро:

• хранение и шардирование сообщений (Раздел 8);
• медиа и CDN — фото, видео, файлы (Раздел 9);
• статусы присутствия — онлайн, «печатает…» (Раздел 7);
• fan-out — доставка в группы и каналы (Раздел 11);
• георепликация — несколько дата-центров по миру (Раздел 13);
• шифрование — транспортное и сквозное (Разделы 14–20).

С чего начинать на доске

Практический вывод раздела: на интервью не вываливай всё сразу. Начни с минимального скелета — клиенты, постоянное соединение, Message-сервис, база — и наращивай подсистемы по мере того, как интервьюер задаёт вопросы. Сначала проведи одно сообщение от Алисы к Бобу, потом усложняй.

Вопросы интервьюера (с разбором)

«Чем мессенджер архитектурно отличается от обычного веб-сервиса „запрос — ответ"?» Образец: «В обычном сервисе инициатива у клиента: он спрашивает — сервер отвечает — связь закрывается. В мессенджере сообщение надо доставить тому, кто прямо сейчас ничего не спрашивает, поэтому сервер должен сам толкать данные на устройство получателя. Для этого нужно постоянное соединение, открытое заранее (WebSocket), а не разовые запросы. Из этого требования и вырастает всё усложнение архитектуры.»

«С чего начнёшь, если просят спроектировать мессенджер? Набросай базовый скелет.» Образец: «Сначала минимальный костяк и одно сообщение по нему. Клиент через балансировщик подключается к серверу соединений, тот передаёт сообщение в Message-сервис — единую точку логики. Message-сервис сохраняет сообщение в базу, смотрит в Реестр сессий, где получатель, и пересылает на его сервер соединений, который доставляет клиенту. От этого скелета наращиваю подсистемы под вопросы — хранение, медиа, группы, присутствие.»

«Какие подсистемы навешиваются на базовый скелет и зачем выносить их отдельно?» Образец: «Поверх ядра доставки появляются хранение и шардирование, медиа с CDN, статусы присутствия, fan-out для групп и каналов, георепликация и шифрование. Выношу их отдельно, потому что у каждой свой характер нагрузки и свои компромиссы — например, присутствие можно делать приблизительным и эфемерным, а сообщения терять нельзя. Сваливать всё в одно ядро значит мешать вещи, которые масштабируются по-разному.»

---

#мессенджер #архитектура #доставка-сообщений #онлайн-и-офлайн #подготовка-к-интервью