Спроектируй чат

Требования

Прежде чем перечислять фичи, спроси себя: что фундаментально отличает чат от обычного API запрос/ответ? Ответ на этот вопрос определяет весь дизайн — tier соединений, реестр, гарантию порядка.

Функциональные: один-на-один и групповая переписка; сообщения доставляются почти в реальном времени, когда получатель онлайн, и ставятся в очередь на доставку, когда офлайн. Галочки доставки — отправлено, доставлено, прочитано (знакомые галочки). Presence — онлайн/был(а) в сети/печатает. Порядок — сообщения в диалоге появляются в консистентном порядке для всех участников. История сообщений персистится и синхронизируется между устройствами пользователя.

Нефункциональные: низкая задержка (сообщение должно прилетать сильно меньше чем за секунду, когда обе стороны онлайн). Надёжная доставка — отправленное сообщение никогда не теряется, даже через дисконнекты, краши и офлайн-получателей; это подразумевает at-least-once доставку плюс дедуп. Огромное число соединений — сотни миллионов устройств, каждое держит долгоживущее соединение, что фундаментально иная задача масштабирования, чем запрос/ответ (ты масштабируешь по одновременным соединениям, а не RPS). Eventual consistency норм для presence и галочек прочтения; порядок внутри диалога должен быть консистентным.

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

Оценка

500M активных в день, большинство держит приложение подключённым, значит порядка сотен миллионов одновременных долгоживущих соединений. Один сервер держит десятки-до-низких-сотен тысяч простаивающих WebSocket (память и файловые дескрипторы на соединение — предел, не CPU), так что нужны тысячи серверов-гейтвеев лишь чтобы терминировать соединения. Объём сообщений: если каждый шлёт ~40 сообщений/день, это 2×10^10 сообщений/день, около 250 000 сообщений/секунду в среднем, кратно на пике. Каждое сообщение мало (сотни байт), так что хранилище доминируется числом, а не размером: ~20 миллиардов сообщений/день по несколько сотен байт — несколько ТБ/день, требуя оптимизированного на запись, горизонтально шардированного хранилища сообщений с политикой хранения.

Вердикт салфетки: ось масштабирования — одновременные соединения, что вынуждает выделенный stateful tier соединений отдельно от stateless бизнес-логики — и способ найти, какой гейтвей держит данного пользователя.

Высокоуровневый дизайн

Система делится на stateful tier соединений и stateless ядро маршрутизации/хранилища.

• Гейтвеи соединений терминируют постоянные WebSocket-соединения. Они stateful (держат сокеты) и существуют лишь чтобы принимать от клиентов и толкать им.
• Чат-сервис stateless: он персистит сообщение (назначая порядковый номер в диалоге), ищет получателя в реестре и форвардит на доставку.
• Реестр соединений отображает юзер/устройство, гейтвей, так что любой инстанс чат-сервиса находит, куда слать сообщение. Обновляется на коннект/дисконнект.
• Хранилище сообщений — долговечная история, шардированная по диалогу, упорядоченная по seq.
• Офлайн-очередь держит сообщения для отключённых пользователей до их переподключения и синхронизации.

Глубокое погружение

WebSocket vs long-poll и tier соединений

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

• Long-polling: клиент делает запрос, который сервер держит открытым, пока не будет сообщения (или таймаута), затем отвечает; клиент сразу перезапрашивает. Это убирает спам пустых поллов, но всё ещё платит новым запросом на сообщение и неловок для всплесков server-push. Это фолбэк для сред без WebSocket.
• WebSocket: одно TCP-соединение, апгрейженное из HTTP раз, остающееся открытым для двунаправленной переписки с крошечным оверхедом фрейминга на сообщение. Сервер может толкать в момент прихода сообщения. Это основной транспорт современного чата.

Поскольку соединения долгоживущие и stateful, tier соединений — своя сущность: ты масштабируешь его добавлением гейтвеев, а крах гейтвея роняет его соединения (клиенты переподключаются, в идеале к другому гейтвею, с backoff и джиттером, чтобы избежать thundering herd переподключений). Реестр обязан обновляться на каждом коннекте/дисконнекте, потому это быстрое in-memory хранилище (в стиле Redis), а не реляционная таблица — churn соединений постоянен.

Доставка сообщений, порядок и три галочки

Надёжная доставка — at-least-once с дедупом. Клиент отправителя назначает клиентский id сообщения; сервер персистит сообщение до ack отправителю (так что крах после ack никогда не теряет его), а получатель дедупит по id сообщения (так что переотправка после переподключения не дублирует). Это даёт пользователю effectively-once.

Порядок — в диалоге, не глобальный — нет осмысленного глобального порядка по всему WhatsApp, лишь «внутри этого чата, в каком порядке произошли сообщения». Чистый способ — назначить монотонный порядковый номер в диалоге при персисте сообщения и рендерить у клиентов по seq. Поскольку все сообщения одного диалога маршрутизируются через и хранятся на одном шарде (шардировано по id диалога), единственный авторитет seq на диалог даёт тотальный порядок без глобальной координации. Клиенты примиряют приход не по порядку (сетевое переупорядочивание, ретраи) по seq.

Три галочки — три состояния доставки, текущие обратно отправителю отдельными событиями:

• Отправлено — сервер персистировал сообщение (одна галочка).
• Доставлено — устройство получателя приняло его, то есть оно было толкнуто в сокет и подтверждено клиентом (две галочки).
• Прочитано — получатель открыл диалог (две синие галочки).

Каждая — подтверждение, идущее обратным путём. Галочки доставлено и прочитано сами — малые сообщения, маршрутизируемые обратно отправителю (и могут батчиться/быть eventual — никому не нужна галочка прочтения за 10 мс).

Presence, офлайн-доставка и групповой чат

Presence (онлайн / был в сети / печатает) — высокочастотное, малоценное на обновление состояние, и трактовать его как сообщения затопило бы систему. Оно живёт в быстром in-memory хранилище по ключу пользователя, обновляется коннектом/дисконнектом гейтвея и хартбитами и читается по требованию. Ловушка масштабирования — fan-out presence: наивно толкать «X вышел онлайн» всем контактам X значит, что событие коннекта популярного пользователя разворачивается в тысячи push. Так что presence обычно тянут (клиент берёт presence контактов, сейчас видимых на экране) или толкают лишь ограниченному заинтересованному набору, и он явно eventual — слегка устаревшее «был в сети» приемлемо, недоставленное сообщение — нет.

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

Групповой чат — снова fan-out. Сообщение в группу на 500 участников должно достичь до 500 получателей. Малые группы разворачиваются на записи (push в путь доставки каждого участника); очень большие группы/широковещательные каналы склоняются к fan-out-on-read или гибриду, ровно как лента — та же логика степенного закона. Доставка каждого участника всё равно течёт через реестр на его гейтвей (или в его офлайн-очередь), и каждый держит свою позицию прочтения в диалоге.

Узкие места и компромиссы

Связывающее ограничение — одновременные соединения, а не темп запросов — чат масштабируется по иной оси, чем типичные веб-сервисы, потому ему нужен выделенный stateful tier гейтвеев. Ключевые компромиссы:

• WebSocket vs long-poll vs поллинг. WebSocket даёт истинный двунаправленный push при минимальной стоимости на сообщение, но нуждается в липких, stateful соединениях и грациозной обработке переподключений; long-poll — фолбэк совместимости; обычный поллинг расточителен и неверен для push (hook).
• Порядок в диалоге vs глобальный порядок. Seq в диалоге даёт тотальный порядок там, где он важен, без глобальной координации; настаивание на глобальном порядке не покупает ничего и тормозит всё.
• At-least-once + дедуп vs exactly-once. Надёжная доставка через переподключения значит at-least-once плюс id сообщения для дедупа (персист до ack); истинный exactly-once по ненадёжной сети недостижим.
• Presence: push vs pull, и eventual. Presence высокочастотен и малоставочен, так что eventual и обычно тянется для видимых контактов; толкать каждое изменение presence катастрофически разворачивается для популярных пользователей.
• Fan-out групп: запись vs чтение. Малые группы разворачиваются на записи; огромные группы/каналы используют read-side или гибридный fan-out — тот же компромисс степенного закона, что у ленты.

Глубочайший принцип: персистентность безусловна, а онлайн-доставка — оптимизация поверх store-and-sync. Персист до ack; используй seq в диалоге и как порядок, и как курсор синхронизации; и никогда не давай «быстрому пути» (push) стать способом потерять сообщение, что «медленный путь» (хранить, затем синхронизировать при переподключении) сохранил бы.