Как пройти System Design Interview

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

Первый содержательный шаг — формализация. До рисования компонентов нужно определить пользователей, контекст, границы задачи и основные сценарии, затем отделить функциональные требования от характеристик качества. Нефункциональные требования нельзя просто собрать длинным списком: доступность, задержка, согласованность, безопасность и стоимость следует расставить по приоритету, потому что они направляют разные архитектурные решения. Грубая оценка нагрузки, объема данных и темпов роста проверяет порядок величин. Для подготовки автор советует изучать use cases, user stories, Jobs to Be Done, ATAM и методы приоритизации требований, но на интервью важен не ритуал, а ясная модель задачи.

После требований кандидат очерчивает систему и ее соседей. На границе могут находиться файлы, базы данных, синхронные API и сообщения; для каждого взаимодействия нужен понятный контракт, направление данных и владелец. Диаграмма System Context из C4 помогает показать пользователей и внешние системы, не погружаясь раньше времени во внутренние сервисы. При обсуждении сетевого пути полезно понимать DNS, TCP, HTTP/1.1–HTTP/3, WebSockets и роль балансировщика, однако перечисление протоколов не заменяет объяснения того, зачем соединение существует и какие гарантии от него требуются.

Компоненты выводятся из потоков, а не появляются из каталога шаблонов. Сначала разбирается счастливый путь, затем чтение и запись, ошибки, повторные запросы и сценарии под нагрузкой. Нотацию выбирают по вопросу: sequence diagram показывает порядок вызовов, activity diagram — ветвления, DFD — движение данных. Концептуальная схема фиксирует обязанности компонентов, состояние и модели данных; здесь уместны различия stateful и stateless, реляционных баз и классов NoSQL, границы предметных областей из DDD и принципы Twelve-Factor. Только затем абстрактные роли получают конкретные технологии с заявленными гарантиями, ограничениями, доменами отказа, мониторингом, журналированием и планом миграций.

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

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