System design интервью: как думать вслух, если ты не архитектор

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

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

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

Структура на 45 минут

Минуты	Что делаешь	Типичная ошибка
0–5	уточняешь требования	сразу рисовать сервисы
5–10	считаешь нагрузку	пропустить и «дизайнить в воздухе»
10–20	верхнеуровневая схема	сразу лезть в детали одного куска
20–35	углубление в один компонент	размазаться по всем сразу
35–42	узкие места и масштабирование	не дойти до них вообще
42–45	итог и что бы улучшил	молча ждать вердикта

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

Шаг 1: сузить задачу

«Спроектируйте Twitter» — это не задание, а приглашение задать вопросы. Что нужно выяснить:

Функциональные требования. Что именно делаем: публикация постов, лента, подписки, поиск, уведомления? Явно проговори, что берём в скоуп, а что оставляем за рамками. «Личные сообщения не проектируем» — нормальная фраза, она сужает задачу и показывает, что ты управляешь временем.

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

Если интервьюер отвечает «решай сам» — озвучь предположение и работай с ним: «предположу 10 миллионов активных в сутки, читают в сто раз чаще, чем пишут; поправьте, если не так». Это сильный ход: ты не завис, а зафиксировал вводные.

Шаг 2: посчитать

Прикидка на салфетке отличает разговор о технологиях от инженерного разговора. Считать нужно вслух и грубо.

Пример на тех же вводных: 10 млн активных пользователей, каждый читает 10 лент в сутки — 100 млн чтений в день. Делим на 86 400 секунд — примерно 1 200 запросов в секунду в среднем, с пиком в три раза выше, то есть порядка 3 500.

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

Хранение: пост в килобайт, миллион постов в сутки — гигабайт в день, терабайт за три года. То есть данных мало, и шардировать пока нечего.

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

Шаг 3: простая схема сначала

Рисуй минимальную работающую версию: клиент, балансировщик, сервис приложения, база, кэш. Всё.

Дальше добавляй компоненты только под конкретную проблему, объясняя, какую именно:

кэш — потому что чтений в сто раз больше, чем записей;
очередь — потому что рассылку уведомлений не нужно делать синхронно;
объектное хранилище и CDN — потому что картинки не должны ходить через приложение;
поисковый индекс — потому что полнотекстовый поиск в основной базе убьёт её.

Обратный порядок — сначала нарисовать десять квадратиков, потом объяснять, зачем они, — самая заметная ошибка. Интервьюер слышит заученную схему вместо мышления.

Шаг 4: назвать компромиссы вслух

Это то, что отличает мидла от сеньора сильнее, чем знание технологий. У любого решения есть цена, и её нужно произносить.

Согласованность против доступности. «Лента может отставать на несколько секунд — для соцсети приемлемо. Для баланса кошелька — нет».

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

Сложность против скорости. «Шардирование сейчас не нужно: терабайт помещается в один узел. Начнём с одной базы и репликой на чтение».

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

Шесть фраз, которые звучат зрело

«Прежде чем проектировать, уточню границы: что входит и что не входит».
«Предположу вот такие цифры, поправьте меня, если порядок другой».
«Самое простое, что здесь сработает, — это…».
«Это сломается, когда…» — и назвать конкретное условие.
«Прежде чем оптимизировать, я бы померил вот это».
«На 45 минут это за рамками, но я бы вернулся к…».

Все шесть — про управление неопределённостью, и именно это в секции проверяют.

Пять способов завалить

Молчать и думать. Секция называется «думать вслух». Пауза дольше десяти секунд не читается никак: интервьюер не знает, ты в тупике или считаешь.

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

Не задать ни одного вопроса. Означает, что ты решаешь не ту задачу.

Утонуть в одном компоненте. Полчаса про схему базы — и до узких мест разговор не дошёл.

Спорить с интервьюером. «А почему бы не сделать проще?» — это подсказка, а не нападение. Правильная реакция — обсудить, а не защищать первый вариант.

Как готовиться за две недели

Возьми пять канонических задач: сокращатель ссылок, лента соцсети, чат, ограничитель частоты запросов, файловое хранилище. Они покрывают почти все механики, которые спрашивают.

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

Пятью задачами набор не заканчивается: у каждой компании свои любимые. Полезно открыть базу вопросов, отфильтровать по system design и по компании, куда идёшь, и посмотреть, что там спрашивали на самом деле.

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

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

Что оценивают на system design интервью?

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

С чего начинать ответ?

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

Нужно ли считать нагрузку?

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

Что делать, если не знаешь технологию?

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

Как готовиться к system design, если нет опыта проектирования?

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

Можно ли начинать с простого решения?

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