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

Задачу сформулировали как упрощённый YouTube: заливка видео, просмотр и лента подписок с оповещением подписчиков о новинках. Кандидат сразу уточнил цифры: 10 миллионов пользователей в день, каждый десятый заливает одно видео в сутки, каждый смотрит около десяти, средняя подписка — на сотню каналов. Ограничения на контент — не больше гигабайта на файл и четыре качества, включая 480; для видео с плохим оригиналом верхние качества просто недоступны.

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

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

Прикидка нагрузки: если каждый обновляет ленту раз пять в день, получается около 50 миллионов запросов в сутки, и делить их удобнее не на 86 400, а на круглые сто тысяч секунд. Отдельный спор вышел про CDN. Кандидат хотел поставить перед ним сервис, отдающий ссылку на видео; интервьюер возразил, что собственной ответственности у такого компонента не вырисовывается — ссылку проще собрать прямо в ответе ленты, а маршрутизацию к ближайшей точке CDN сделает сам.

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

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