System design интервью: как устроена секция и как её пройти

Что на самом деле оценивают на секции

System design интервью проверяет не эрудицию, а способ мышления: как вы сужаете неопределённую задачу до проектируемой, чем жертвуете и умеете ли объяснить, почему именно этим. Формулировка «Спроектируйте Twitter» намеренно недоопределена — в ней нет ни требований, ни масштаба, ни ограничений. Это и есть первая часть задания.

Интервьюер заполняет внутреннюю анкету, и пункты в ней примерно такие:

• Сузил ли кандидат задачу сам. Сколько пользователей, какие сценарии входят в объём, какие вынесены. Кандидат, который начинает рисовать схему с первой минуты, проектирует систему, которую у него никто не просил.
• Связаны ли решения с требованиями. Кэш появился, потому что чтений в десять раз больше записей, — или потому что кэш положено рисовать.
• Признаёт ли компромисс. Каждое решение что-то ухудшает. Кандидат, у которого всё только улучшается, либо не понимает своего решения, либо защищается.
• Расставляет ли приоритеты. За 45 минут нельзя спроектировать всё. Сильный кандидат вслух выбирает, куда потратить время, и обосновывает выбор.
• Можно ли с ним работать. Как реагирует на возражение, слышит ли подсказку, спорит по существу или по статусу.

Отсюда следует неочевидное: знание паттернов — необходимое, но не решающее условие. Инженер, помнящий все главы про consistent hashing, заваливает секцию, если сорок минут строит монолог; инженер со средним багажом проходит, если разговор с ним похож на настоящее проектное обсуждение. Подготовка к system design интервью, которая сводится к чтению разборов, тренирует только первую половину навыка.

Каркас ответа: семь шагов

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

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

Шаг 1. Требования

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

Шаг 2. Оценки нагрузки

Считать нужно вслух, круглыми числами и с проговариванием допущений. Точность не проверяется — проверяется, умеете ли вы вывести из бизнес-величин технические. Работающий пример на задаче с сокращателем ссылок:

Допустим, 100 млн новых ссылок в сутки.
  → записи: 100e6 / 86400 ≈ 1 160 запросов/с, пик ×3 ≈ 3 500/с
  → чтения при соотношении 10:1 ≈ 11 600/с, пик ≈ 35 000/с
  → хранение за 5 лет: 100e6 × 365 × 5 ≈ 1,8e11 записей
  → при 500 байт на запись ≈ 90 ТБ

Вывод, который отсюда следует:
  - 1,8e11 записей не помещается в base62 длиной 6 (5,7e10),
    беру 7 знаков — это 3,5e12, запас есть;
  - 90 ТБ на один узел не кладём — нужен шардинг с самого начала;
  - профиль «читаем в 10 раз чаще, чем пишем» → кэш на чтении
    и реплики, а не оптимизация записи.

Обратите внимание на вторую половину блока. Цифры сами по себе не стоят ничего — ценность в том, что каждая из них превращается в проектное решение. Кандидат, который посчитал QPS и тут же о нём забыл, потратил четыре минуты впустую.

Шаги 3–4. API и данные

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

Шаги 5–7. Схема, узкие места, компромиссы

Схема рисуется в одну строку компонентов и не должна занимать больше десяти минут: это опора для разговора, а не результат. Дальше начинается то, ради чего секция и проводится: вы сами атакуете собственное решение. Что произойдёт при росте в десять раз, где горячий ключ, что будет при отказе узла, что при отказе целой зоны, как система ведёт себя при повторной доставке сообщения. Хороший финал — минута на итог: что выбрали, чем заплатили, что бы поменяли, будь у вас неделя.

Первые пять минут: вопросы интервьюеру

Это самый недооценённый участок секции. Кандидат, начинающий с уточняющих вопросов, отличается от остальных сильнее, чем кандидат, знающий лишний паттерн. Держите в голове короткий список и задавайте только то, что действительно меняет решение.

ОБЪЁМ
- Какие сценарии обязательны? Назову три, скажите, если пропустил важное.
- Что считаем вне объёма: авторизация, модерация, биллинг, аналитика?
- Проектируем первую версию или систему, уже работающую под нагрузкой?

МАСШТАБ
- Сколько активных пользователей и какой горизонт роста?
- Соотношение чтений и записей?
- География: один регион или несколько?

КАЧЕСТВА
- Что важнее при сбое: отдать устаревшие данные или не отдать ничего?
- Приемлемая задержка на основном сценарии?
- Допустима ли потеря отдельной записи или требуется гарантия доставки?

ПРОЦЕСС
- Куда мне углубиться подробнее, а что описать крупно?
- Считаем инфраструктуру доступной как облачные сервисы
  или проектируем компоненты сами?

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

Четыре типовые задачи и их развилки

Задачи на секции повторяются, но ценность разбора не в готовой схеме, а в том, где именно проходит развилка и какой вопрос делает выбор осмысленным.

Сокращатель ссылок

Главная развилка — как рождается короткий код. Счётчик с кодированием в base62 даёт компактность и отсутствие коллизий, но требует координации между узлами и выдаёт предсказуемые последовательные адреса. Хеш от URL с усечением до семи знаков не требует координации, но приносит коллизии, которые надо разрешать. Предварительно сгенерированный пул ключей снимает и то, и другое, но добавляет фоновый процесс и состояние, которое можно исчерпать.

Второй разговор — про чтение. Профиль 10:1 в пользу чтений означает кэш, и интервьюер почти наверняка спросит про инвалидацию и TTL. Третий — что делать с истёкшими ссылками: удалять сразу или помечать и чистить пакетно (правильный ответ обычно второй, и объяснить нужно почему).

Лента новостей

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

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

Мессенджер

Здесь развилки не про масштаб, а про гарантии. Соединение — долгоживущее, поэтому появляется реестр «пользователь → узел» и вопрос, что происходит при падении узла. Доставка — at-least-once плюс идемпотентность по клиентскому идентификатору сообщения: exactly-once на сети не существует, и кандидат, который это произносит вслух, набирает очки. Порядок сообщений — по последовательности внутри диалога, а не по времени сервера. Хранение — партиционирование по идентификатору диалога, потому что весь доступ идёт именно так.

Загрузка файлов

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

Как думать вслух

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

Структура одной реплики, которая работает почти везде: что я сейчас делаю → какие варианты вижу → что выбираю → чем плачу.

Три приёма, которые ставят этот навык:

• Проговаривайте развилку до выбора, а не после. «Вижу два пути» звучит как размышление; «я выбрал X, а вообще был ещё Y» — как оправдание.
• Называйте допущение вслух и идите дальше. «Считаю, что просмотры можно терять, точность там не нужна» — интервьюер поправит, если не согласен, и это дешевле, чем полсекции в неверную сторону.
• Тренируйтесь с таймером и голосом. Разбор в голове занимает пять минут, тот же разбор вслух — двадцать. Разница обнаруживается на интервью и в самый неподходящий момент.

Где заваливаются

Отдельно про масштаб: у большинства кандидатов проблема не в том, что они не знают про шардинг, а в том, что вводят его без повода. Если из ваших же оценок следует 90 ТБ — шардинг обоснован. Если следует 200 ГБ, а вы всё равно шардируете, это тот же провал, что и обратный, просто в другую сторону.

Что читать

Основной источник по теме — «System Design Interview» Алекса Сюя: две книги разбирают полтора десятка типовых задач по единому каркасу, и как справочник по развилкам они устроены лучше большинства курсов. Покупать стоит легально — у книги есть официальное издание, и запрос вида «system design подготовка к сложному интервью скачать» ведёт обычно к плохо распознанным копиям с перевранными схемами, что в техническом тексте хуже, чем отсутствие текста.

Чего в книге нет — и это не претензия, а границы жанра. Она даёт готовые разборы, но не даёт того, что происходит на самой секции: как звучит ваша речь под таймером, что делать, когда интервьюер задаёт вопрос из области, которую вы не открывали, и как выглядит ваш ответ со стороны. Разборы читаются глазами, а проверяются вслух. Поэтому подготовка к system design интервью состоит из двух непохожих частей: чтение развилок и наговаривание решений в голос — лучше с человеком, который перебивает.

Где здесь Whisperer

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

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

Второе — режим System Design: отдельный формат ответа, в котором модель выдаёт структурированный разбор с уточнением требований, оценкой масштаба, текстовой диаграммой компонентов и явным списком компромиссов. На macOS схема рендерится прямо в окне ответа, на Windows приходит кодом диаграммы. Это удобный спарринг-партнёр при самоподготовке: набросали своё решение, попросили альтернативу, сравнили развилки. Рядом работают AI-подсказки и разбор скриншотов, если схему рисуют на общей доске. Старт бесплатный — 60 минут.

Отдельно про рамку: здесь речь о подготовке и разборе собственных ответов, а не о подсказках в обход правил работодателя. Где проходит граница между помощью и обманом на живом собеседовании — разбирается в отдельном материале про ИИ на собеседовании. Если вы по другую сторону стола и проводите интервью сами, полезен разбор структурированного интервью: одинаковые блоки и критерии для всех кандидатов.

Частые вопросы