Техническое интервью: Архитектурная секция

Секцию открывает ведущий главной студии Александр Воронков: накануне на конференции разбирали алгоритмическую секцию, сегодня очередь архитектурной. Интервьюер — Александр Поломодов, который почти шесть лет руководит одним из направлений в своей компании и курирует то, как там проводят интервью по system design. Кандидат — Владимир Иванов: около девяти лет в 2ГИС, последние пять — в разработке кроссплатформенного мобильного приложения на C++; с высоконагруженным бэкендом он в работе напрямую не сталкивается и сам считает, что от этого будет только интереснее. Формат Александр проговаривает сразу: проектируем итеративно, от простого к усложнению, вопросы можно задавать в любой момент, а у него самого две роли — отвечать на уточняющие вопросы о том, как система будет использоваться и что здесь важно, и быть техническим инженером, который вместе с кандидатом обсуждает предложенные решения. Владимир формулирует задачу своими словами: получается упрощённый YouTube. Интервьюер соглашается.

Требования висят на экране, и Владимир начинает с цифр. Аудитория — 10 миллионов пользователей в день; заливает видео каждый десятый, по одному в сутки; смотрит каждый около десяти; подписан в среднем на сотню каналов. Граф подписок договорились считать равномерным и супер-популярные каналы пока не учитывать: кандидат вспомнил про них почти сразу, интервьюер отметил это как хороший ход, но отложил тему на конец, чтобы успеть основное. Ограничения на контент: файл не больше гигабайта, четыре качества, включая 480, причём для видео с плохим оригиналом верхние качества просто недоступны. Пользователей считаем размазанными по часовым поясам. Границы очертили быстро — клиентская часть остаётся за скобками, проектируется публичный бэкенд-API, а как им пользуются мобильные разработчики, остаётся их заботой. Аналитику, мониторинг, юридические вопросы, аутентификацию и авторизацию выбросили: модельная задача урезана специально, чтобы её можно было нормально обсудить за час. Хранение подписок — внешний сервис, а собранная лента уже своя.

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

Ленту собирают на запись. Как только видео готово, его идентификатор разносят по лентам всех подписчиков: ждать сборки в момент открытия ленты пользователь не станет, и грустно, если он попросит показать новинки подписок и будет долго ждать. Саму ленту кандидат видит как key-value «пользователь → его лента», хотя допускает и обычную таблицу в реляционной базе; из атрибутов в модельной задаче остаются название и картинка. Отсюда развилка, которую подсвечивает интервьюер: либо денормализовать в ленту название и ссылки на все размерности и больше ничего с ними не сделать, либо держать их в базе и подклеивать при чтении. Прикидка нагрузки: если ленту открывают раз пять в день, выходит около 50 миллионов запросов, и делить их удобнее на круглые сто тысяч секунд, а не на 86 400. Шардирование ленты по идентификатору пользователя работает из коробки, а сломать его могут разве что чересчур активные аккаунты, которые не хочется собирать в одном шарде.

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

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