Раздел 2. Требования и рамки задачи

Самая частая ошибка на system design интервью — услышав «спроектируй мессенджер», сразу хвататься за маркер и рисовать серверы. Этот раздел про то, что идёт до рисования: как сузить задачу, разложить требования и прикинуть масштаб. Грамотный кандидат тут зарабатывает половину впечатления ещё до первой стрелочки на доске.

Сначала — уточняющие вопросы

«Спроектируй мессенджер» — это нарочно расплывчатая формулировка. WhatsApp, корпоративный чат и канал на десять миллионов — это очень разные системы. Поэтому первый ход — сузить scope уточняющими вопросами:

• Что входит (scope): только диалоги 1-на-1 или ещё группы и каналы? Медиа? Статусы прочтения, presence, звонки? Лучше явно отрезать лишнее: «давайте сфокусируемся на личной переписке с медиа, а звонки вынесем за рамки».
• Масштаб: десятки тысяч пользователей или сотни миллионов DAU? От этого зависит вообще всё — одна машина или сотни узлов и георепликация.
• Гарантии: какая допустимая задержка? Насколько критична потеря сообщений? Нужен ли строгий порядок?

Смысл не в том, чтобы засыпать интервьюера вопросами, а в том, чтобы показать: ты сначала договариваешься о рамках, а потом проектируешь под них.

Функциональные и нефункциональные требования

Дальше требования раскладывают на два списка — на доске их полезно явно разделить:

• Функциональные (FR) — что система умеет: отправлять диалоги и групповые сообщения, слать медиа, показывать статусы, искать по истории.
• Нефункциональные (NFR) — насколько хорошо она это делает: задержка, доступность, масштаб, консистентность, надёжность хранения.

Для мессенджера именно NFR определяют архитектуру. «Отправить сообщение» звучит просто, но «отправить сто тысяч сообщений в секунду, не потеряв ни одного, с задержкой в доли секунды и доступностью почти 100%» — это уже совсем другой разговор.

Прикидка нагрузки (back-of-the-envelope)

Прежде чем выбирать технологии, прикидывают порядок цифр — грубо, «на коленке». Точность не нужна, нужен масштаб: тысячи в секунду или сотни тысяч. Считают примерно так:

• сообщений в день = DAU × среднее число сообщений на пользователя;
• средний QPS = сообщений в день / 86 400 (секунд в сутках);
• пиковый QPS = средний × коэффициент пика (обычно 3–10) ← проектируем под пик, а не под среднее;
• хранилище в год = сообщений в день × средний размер × 365.

Пример на цифрах: 50 млн DAU × 40 сообщений ≈ 2 млрд сообщений в день ≈ 23 тыс/сек в среднем ≈ **115 тыс/сек на пике**. Отдельно сразу видно, что в объёме хранилища доминирует медиа, а не текст, — значит, под файлы понадобится отдельное хранилище и CDN (Раздел 9).

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

Консистентность против доступности

Ключевой компромисс, который задают здесь и переиспользуют весь курс. Когда что-то ломается (разрыв между регионами, отказ узла), приходится выбирать: либо ждать согласования данных (строгая консистентность), либо отвечать из локальной, возможно чуть устаревшей копии (доступность).

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

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

Главное одной фразой

Не рисуй сразу. Сначала сузь задачу вопросами, раздели FR и NFR, прикинь нагрузку под пик, и зафиксируй главный компромисс: доступность важнее строгой консистентности порядка, но durability — свята. Эта рамка дальше определит почти каждое решение.

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

«Тебе говорят „спроектируй мессенджер". С чего начнёшь?» Образец: «Не с рисования. Сначала сужу задачу уточняющими вопросами: что входит в scope — диалоги, группы, медиа, звонки; какой масштаб в DAU; какие гарантии по задержке, потерям и порядку. Дальше разделяю требования на функциональные и нефункциональные, прикидываю нагрузку под пик и только потом начинаю рисовать скелет под зафиксированные рамки.»

«Прикинь на коленке нагрузку: сколько сообщений в секунду и сколько хранилища?» Образец: «Беру DAU и среднее число сообщений на пользователя. Допустим, 50 млн × 40 — это 2 млрд сообщений в день. Делю на 86 400 секунд — порядка 23 тысяч в секунду в среднем, и проектирую под пик, умножая на коэффициент 3–10, — около 115 тысяч в секунду. Под хранилище отдельно считаю объём за год и сразу отмечаю, что доминирует медиа, поэтому ему нужно отдельное хранилище и CDN. Точные числа неважны — важен порядок и проектирование под пик.»

«Что выбираешь — консистентность или доступность, и где граница?» Образец: «Для мессенджера склоняюсь к доступности: лучше доставить сейчас и согласовать порядок и статусы чуть позже (eventually consistent), чем вставать ради строгой согласованности. Небольшая неточность присутствия или порядка терпима. Но граница жёсткая: это касается порядка и состояния, а не сохранности — durability сообщения я не ослабляю, потеря недопустима. Доступность размениваю, надёжность хранения — нет.»

---

#мессенджер #требования #прикидка-нагрузки #нефункциональные-требования #консистентность-доступность #подготовка-к-интервью