System Design на собеседовании: как проходит секция и что оценивают

Как устроена секция §

Т-Банк и Яндекс описали секцию публично, и в главном описания сходятся. Т-Банк даёт набор функциональных требований и час, за который нужно формализовать задачу, спроектировать API, оценить нагрузку и необходимые мощности, спроектировать модели и потоки данных. Рисуют на онлайн-доске вроде Miro, Sketchboard или Excalidraw.

У Яндекса архитектурная секция занимает полтора часа. Из них час отведён на задачу, остальное уходит на организационные моменты. Зовут на неё только кандидатов с коммерческим опытом проектирования высоконагруженных распределённых систем.

Единой длины у секции нет. Кандидат, описавший собеседования в двух зарубежных компаниях, приводит раскладку на 40–45 минут. Точную длину назовёт рекрутёр, и спросить её лучше заранее: от неё зависит, сколько времени останется на погружение в детали.

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

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

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

Что в ней оценивают §

Шкалу, по которой решение превращается в оценку, компании не публикуют. Публично описано, на что смотрят. Страница найма Яндекса называет шесть вещей:

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

Перечень Т-Банка короче и во многом с этим списком совпадает: формализация задачи, API, нагрузка и мощности, модели и потоки данных.

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

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

Фазы и куда уходит время §

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

Раскладки времени в публичных разборах расходятся. В одной из часа на знакомство и требования уходит около пятнадцати минут, на API пять-десять, на данные около десяти, на схему около пятнадцати, а на сам дизайн остаётся минут сорок. В другой, рассчитанной на 40–45 минут, требованиям отдано пять. Общее у них одно: требования идут первыми, и рисовать до них не советует ни одна.

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

Если времени меньше часа, сокращайте середину. Требования и оценка нагрузки занимают мало, а всё остальное выводится из них. Второй рычаг — охват. Кандидат, описавший раскладку на 40–45 минут, советует выбрать около трёх основных функций, а остальное прямо назвать вне границ задачи: иначе их и будут от вас ждать.

Как считать нагрузку §

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

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

Гипотеза: 10 млн активных пользователей в сутки,
каждый открывает ленту 20 раз и публикует 1 пост.
 
Чтение:  10 млн × 20 = 200 млн в сутки
         200 млн ÷ 86 400 с ≈ 2 300 запросов/с в среднем
         пик: допустим, втрое выше среднего ≈ 7 000 запросов/с
Запись:  10 млн ÷ 86 400 с ≈ 116 запросов/с
Объём:   10 млн постов × 1 КБ = 10 ГБ в сутки ≈ 3,7 ТБ в год

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

В примере из блога Яндекса про сервис коротких ссылок разрыв ещё резче. Изменений данных порядка 10–20 запросов в секунду, и с ними справится один сервер. Переходов по ссылкам в пике 500 тысяч в секунду. После такого расчёта ясно, какой половине системы отдать оставшееся время.

Для прикидки в уме в сутках удобно считать 100 000 секунд вместо 86 400. Результат выйдет примерно на 14 % ниже точного, для порядка величины это не важно.

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

Ошибки в этой арифметике случаются и без стресса. В трёх наших разборах проверка нашла ошибку в расчёте. В первом нагрузку на приём писем посчитали по всему потоку, включая исходящие, и завысили её на четверть. Во втором три миллиона точек графика отнесли к одному пикселю, хотя это был целый год данных, а на пиксель приходилось три тысячи. В третьем исходный набросок давал объём хранения в десять раз больше верного: 10 млн пользователей × 2 фото в месяц × 5 МБ дают 100 ТБ в месяц, а в наброске стояло 1000. Все три ошибки нашлись потому, что арифметика была записана. Расчёт, сделанный в уме, не проверит ни интервьюер, ни вы сами.

Дефекты схемы, которые находит проверка §

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

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

Механизм есть в рассказе, но нет на схеме. Нашёлся во всех 30 разборах. Требование, метод API или абзац объяснения говорят о компоненте, а узла на схеме нет. На доске остаётся система без той части, о которой вы только что рассказывали.

Контур не замкнут. 29 разборов из 30. Запрос уходит в систему, а ответ не возвращается тому, кто спросил. Или в хранилище пишут, но из него никто не читает. Кэш, в который ничего не кладут, кэшем не работает.

Решение на пути запроса нарисовано прямоугольником или простой стрелкой. 25 из 30. Лимит частоты, проверка дубля, истёкший таймаут: здесь запрос может не пройти дальше. Если развилки нет, нет и ветки отказа, и схема описывает систему, у которой всё всегда получается.

Хранилище делает работу службы. 9 из 30. Из базы выходит готовый результат, решение или уведомление. Хранилище отдаёт данные, решает тот, кто их прочитал. Когда это не видно, непонятно, где живёт логика и что станет узким местом.

Порядок не показан или показан неверно. 7 из 30. Две стрелки из одного узла читаются как «в любом порядке». Бывает, что порядок и есть гарантия: сначала записать данные, потом ссылку на них, иначе в списке появится запись, которая не открывается. Такие шаги нумеруют.

Проверка своей схемы по этим пяти пунктам занимает минуту. Удобнее всего сделать её перед разговором о компромиссах:

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

Где решение проваливается по существу §

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

Чаще других повторяются шесть:

• Пересчёт на каждый запрос. Обход всего набора данных, сортировка или ранжирование в момент запроса там, где результат можно подготовить заранее. Записан в 14 задачах из 43.
• Каждое событие как запись в основную базу. Счётчик в строке, баланс изменяемым полем, каждый сигнал отдельной транзакцией. На популярном объекте такая строка становится узким местом. 12 задач.
• Решение без числа. Шардирование данных, которые помещаются на один сервер, репликация на всякий случай, приблизительная структура без посчитанной ошибки. 12 задач.
• Тяжёлая работа внутри обработчика запроса. Отправка во внешнюю систему, перекодирование, рассылка подписчикам, пока клиент ждёт ответа. 11 задач.
• Нет ответа на отказ. Потеря ведущего узла, холодный старт кэша, перезапуск процесса с открытыми соединениями. 9 задач.
• Обещанная гарантия, которой нет. «Ровно один раз», глобальный порядок, точный счёт в реальном времени. 8 задач.

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

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