Подготовка к собеседованию по системному дизайну за четыре недели

Сильное собеседование по системному дизайну - это управляемый разговор, а не проверка памяти. Вам нужен достаточно широкий технический кругозор, чтобы распознать характер задачи, практика для принятия решений по таймеру и дисциплина, чтобы объяснить, почему каждое решение подходит под заявленные требования. Четырех недель хватит, чтобы развить этот навык, если тренировать результат, а не собирать очередные материалы для чтения.

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

Сначала оценочная таблица, потом учебный план

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

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

Оцените попытку от нуля до двух по каждому пункту:

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

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

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

На первой неделе закрепите повторяемый ход интервью

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

В первый день соберите набор вопросов по функциональным требованиям. Для каждой задачи спрашивайте, кто создает данные, кто их читает, какое действие должно ощущаться мгновенным, что можно выполнить позже, что требуется хранить и у кого должен быть доступ. Уточните ожидаемый масштаб и географию. Затем скажите, что оставляете за рамками. Последняя фраза не даст расплывчатой задаче разрастись до размеров, которые нельзя охватить на собеседовании.

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

Пользуйтесь такой короткой памяткой:

traffic = active users x actions per user / active seconds
peak traffic = average traffic x stated peak factor
storage = writes per day x bytes per record x retention days
bandwidth = requests per second x bytes per response

На третий и четвертый дни сопоставьте действия с интерфейсами и постоянными сущностями. Если продукт позволяет создать, изменить, получить, вывести списком и удалить объект, запишите эти операции до того, как рисовать блоки. Определите идентификаторы, поведение при повторном запросе, постраничную выдачу и поля для основного чтения. Затем выберите модель данных под эти способы доступа. Не берите документную базу только потому, что данные похожи на JSON, и реляционную только потому, что у сущностей есть названия. Решение определяют путь доступа, граница транзакции и характер роста.

На пятый и шестой дни проведите два проектирования по 45 минут. Сокращатель ссылок и ограничитель частоты запросов полезны тем, что проверяют разные навыки. Первая задача затрагивает идентификаторы, преобладание чтения, поведение кеша и защиту от злоупотреблений. Вторая проверяет область действия лимита, временные окна, атомарные обновления, допущения о часах и политику при отказе. На седьмой день просмотрите материалы и перепишите только самое слабое начало. Отдых полезнее третьего полного проектирования, когда внимание уже рассеялось.

Вторая неделя посвящена движению данных и масштабу

На второй неделе сосредоточьтесь на движении данных, когда одной машины или одного синхронного запроса уже мало. Чаще всего понадобятся секционирование, репликация, кеширование, очереди, индексы и согласованность. Изучайте каждый прием как ответ на измеренное ограничение, а не как блок, который делает схему солиднее.

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

Репликация отвечает за работу системы при потере узла и за обслуживание удаленных читателей. Умейте объяснить разницу между синхронной и асинхронной репликацией, не объявляя один вариант безусловно лучшим. Синхронное подтверждение может дать более строгую гарантию сохранности или согласованности ценой задержки и доступности при разделении сети. Асинхронные реплики сокращают задержку записи, но иногда отдают устаревшие данные или теряют подтвержденные записи в узком окне отказа. Конкретное поведение зависит от базы и правил переключения.

Относитесь к кешу как к политике согласованности, к которой добавлено хранилище. RFC 9111 описывает поведение HTTP-кеша через правила актуальности, проверки и сброса. Для собеседования полезен более общий вывод: назовите, кто отвечает за актуальность, когда запись истекает, что происходит после изменения и как система ведет себя при недоступном кеше. Фраза «добавим Redis» не отвечает ни на один из этих вопросов. В каждом пробном проектировании выберите кеширование по запросу, сквозную запись или отказ от кеша и объясните, какую проблему вы устраняете и какую создаете.

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

Закончите неделю проектированием новостной ленты и конвейера обработки файлов. Лента заставит выбирать между расчетом при чтении и заблаговременным распространением записей. Конвейер потребует обсудить объектное хранилище, метаданные, асинхронную работу, повторы и состояния выполнения. Проведите каждое проектирование дважды. Во второй раз измените одно требование, например добавьте аккаунты знаменитостей или строгий срок завершения, и перестройте решение вместо защиты вчерашнего варианта.

На третьей неделе явно опишите поведение при отказе

Третья неделя превращает правдоподобную схему в систему, которую можно эксплуатировать. Интервьюеры часто спрашивают про отказы, потому что назвать компоненты для счастливого пути легко. Вы должны уметь сказать, что ломается, что видит вызывающая сторона, как возобновляется работа и откуда оператор знает, что восстановление идет нормально.

Начните с тайм-аутов и повторов. Каждому удаленному вызову нужен бюджет времени. Повтор может помочь при временном сбое, но синхронные повторы способны многократно увеличить нагрузку на больную зависимость. Тренируйте ограниченную экспоненциальную задержку со случайным разбросом, общий крайний срок и правило о том, какие ошибки безопасно повторять. Затем свяжите повторы с идемпотентностью. Если повторный запрос может еще раз списать деньги или создать второй заказ, API нужен стабильный ключ запроса и надежное устранение дублей на границе побочного эффекта.

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

Используйте подход к бюджету ошибок из книги Google Site Reliability Engineering как средство принятия решений, а не лозунг. Полезная мысль проста: цель по надежности оставляет измеримый запас на сбои. На собеседовании превратите ее в поведение: какая доступность нужна каждому методу, какая зависимость забирает большую часть бюджета задержки и когда команда прекращает рискованные изменения ради восстановления надежности. Не обещайте пять девяток только потому, что это звучит по-взрослому. Более строгие цели стоят денег и сужают выбор архитектуры.

Проследите один отказ до конца. Допустим, обработчик записал строку, упал до подтверждения сообщения и после перезапуска получил то же сообщение снова. При безусловной вставке появится дубль. Если записать ключ идемпотентности и результат в одной транзакции с основной строкой, вторая попытка сможет вернуть первый результат. Если побочный эффект находится вне этой транзакции, понадобится исходящая очередь, механизм идемпотентности провайдера или сверка. Такая глубина отличает рассказ о восстановлении от фразы «очередь повторит».

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

Четвертая неделя превращает знания в результат на интервью

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

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

После каждого пробного интервью соблюдайте строгий цикл разбора:

1. Запишите первую минуту, когда проектирование пошло не туда.
2. Найдите пропущенный вопрос или решение, которое стало причиной.
3. Переделайте только этот фрагмент длиной от пяти до десяти минут.
4. На следующий день повторите фрагмент без записей.
5. Проверьте, повторилась ли та же ошибка на следующем полном интервью.

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

В последние два дня снизьте нагрузку. Просмотрите оценочные таблицы, лист с расчетами, пары компромиссов и три разбора отказов. Один раз легко потренируйте начало и остановитесь. Сон и исправный микрофон помогут больше, чем ночной обзор протоколов консенсуса. Вы готовитесь рассуждать вслух, а для этого нужно внимание, которое зубрежка отнимает.

Частота темы определяет глубину изучения

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

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

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

Третий уровень заполните материалом под конкретную роль. Для работы с хранилищами могут потребоваться LSM-деревья, уплотнение, фильтры Блума и поведение кворума. Для работы с медиа пригодятся кодеки, манифесты, доставка контента и перекодирование. Для платформы машинного обучения важны свежесть признаков, соответствие автономной и рабочей обработки, выпуск моделей и обнаружение дрейфа. Прочитайте описание вакансии и свежие инженерные материалы компании, затем поднимите нужные пункты выше. Частота зависит от контекста, а не одинакова везде.

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

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

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

Консенсусу нужно отвести правильное место. Следует понимать, зачем системе согласие, что делает лидер и как разделение сети влияет на возможность двигаться дальше. На большинстве общих интервью выводить Raft с нуля не придется. Зато от вас ждут, что вы не поставите распределенную блокировку или группу консенсуса в каждый запрос без разговора о задержке и доступности. Сначала разберитесь с абстракцией, потом с механикой статьи, если только должность не требует обратного.

Разбор компромисса должен закончиться решением

Хорошее объяснение связывает требование с выбором, называет цену и задает условие для пересмотра. Фраза «SQL или NoSQL - зависит от ситуации» лишь повторяет неопределенность. Фраза «запись заказа охватывает состояние запасов и платежа, поэтому для транзакционных ограничений я возьму реляционное хранилище; если позже начнет преобладать чтение, построю отдельную модель чтения из журнала изменений» дает интервьюеру решение, которое можно проверить.

Для каждого крупного решения используйте конструкцию из четырех частей:

Because [requirement or estimate], I will choose [design].
This gives us [specific benefit] but costs [specific downside].
I am rejecting [credible alternative] because [reason in this prompt].
I would revisit the choice if [measurable condition changes].

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

Объясняйте ход мысли на границах решений, а не непрерывно. Скажите, какую часть схемы рисуете, примите решение, объясните его и спросите, хочет ли интервьюер углубиться. Непрерывная речь может скрыть архитектуру. Долгое молчание прячет рассуждение. Удобный ритм - двадцать или тридцать секунд объяснения, затем короткая проверка общего понимания. Просить разрешения на каждый блок не нужно.

Если интервьюер оспаривает выбор, не воспринимайте это как вердикт. Повторите изменившееся ограничение и проследите последствия. «Если пользователи должны видеть собственную запись в разных регионах, асинхронная реплика для чтения больше не выполняет требование. Можно направить пользователя в регион записи, дождаться репликации по токену сессии или заплатить за более строгую модель записи в нескольких регионах. Какая цель по задержке здесь важнее?» Такой ответ дает варианты и не делает вид, будто они бесплатны.

Статья о Dynamo полезна тем, что объясняет нестрогий кворум и отложенную передачу как способы продолжать прием работы при сбоях, а также описывает разрешение конфликтов. Из нее не следует копировать Dynamo в каждую архитектуру. Выбор в пользу доступности переносит сложность в сверку, семантику приложения и эксплуатацию. Если задача не допускает конфликтующих версий, скажите об этом до того, как заимствовать прием, который на них рассчитан.

Уберите из устного ответа пустые формулировки. Фраза «для масштабирования можно использовать балансировщик нагрузки» называет компонент, но не решение. Уточните, завершает ли он соединения, направляет ли запросы по региону или клиенту, проверяет ли состояние узлов или защищает перегруженную группу. Если пока ни одно из этих действий не нужно, не рисуйте блок. Интервьюер способен оценить ошибочный выбор с объяснением, но декоративный прямоугольник оценить нельзя.

Разбор задачи показывает, куда уходят минуты

Сервис уведомлений удобен для репетиции, потому что объединяет пользовательские настройки, несколько каналов доставки, всплески, повторы, отказы провайдеров и отслеживание статуса. Начните с границ: принимать запросы на уведомления от внутренних продуктов, учитывать предпочтения пользователей, доставлять электронные письма и push-уведомления, показывать состояние доставки. Интерфейсы создания сообщений и маркетинговую сегментацию исключите, пока интервьюер их не добавит.

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

Определите интерфейс с ключом идемпотентности от вызывающей стороны, получателем, ссылкой на шаблон, параметрами, запрошенными каналами и приоритетом. Верните идентификатор уведомления и статус приема. Сохраните запрос и запись исходящей очереди в одной транзакции. Ретранслятор публикует задания по каналам из этой очереди, закрывая разрыв между успешной записью в базу и сбоем публикации. Обработчики каналов читают настройки, формируют сообщение, вызывают провайдеров и записывают попытки.

Разделяйте задания по получателю, если важен порядок для одного пользователя. Если общий порядок не нужен, не платите за него. Разнесите очереди по каналам и, возможно, приоритетам, чтобы медленный почтовый провайдер не задерживал срочные push-сообщения. Ограничивайте повторы по ответу провайдера и сроку жизни сообщения. Ссылка для сброса пароля, пришедшая завтра, провалила задачу, даже если обработчик в итоге отметил ее доставленной.

Модели данных нужны записи уведомления, попытки доставки, настройки и ключи идемпотентности. Отделяйте неизменные факты запроса от меняющегося состояния доставки. Индексируйте запросы статуса по идентификатору уведомления, а эксплуатационные запросы по состоянию и времени следующей попытки. Архивируйте или удаляйте подробную историю попыток по явно заданному сроку. Оставить ее расти без границ нельзя.

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

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

За пять минут до конца повторите основной путь и принятую цену. Архитектура отдает приоритет быстрому приему и изолированной доставке ценой итоговой согласованности статуса и защиты от дублей. Запрос и исходящая очередь хранятся вместе, но обращения к провайдерам остаются вне этой транзакции. Самый глубокий нерешенный вопрос - продуктовая политика для неоднозначных результатов провайдера. Это убедительное завершение, потому что оно указывает на настоящую границу и не объявляет систему законченной.

Уровень должности меняет ожидаемый разговор

Одна задача проверяет разные навыки на разных уровнях. От специалиста среднего уровня ждут связный путь, разумные компоненты и объяснение базового масштабирования и отказов. Старший специалист должен управлять объемом, показывать организационную и эксплуатационную цену, видеть пути миграции и спрашивать, какое бизнес-ограничение оправдывает сложность. На уровне staff разговор часто доходит до границ ответственности, интерфейсов между командами, риска выпуска и развития архитектуры без остановки трафика.

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

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

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

В день интервью запишите требования и критерии успеха там, где их видят оба участника. Рядом со схемой держите небольшой бюджет времени. Когда времени остается мало, закончите один основной путь и один путь отказа, прежде чем добавлять необязательные возможности. Законченный аргумент об ограниченной системе лучше амбициозной схемы, стрелки которой не объясняют происходящее.