Публичное System Design Interview на конференции C++ Russia 2022

Описание задачи

Требуется спроектировать приложение, которое будет позволять загружать видео создателям контента и просматривать это видео всем остальным. Аналоги всем известны.

Функциональные требования

Нам требуется спроектировать сервис, которые позволит реализовать следующие фичи

  • Система должна позволять создателям каналов быстро заливать видео
  • Видео должно по готовности попадать в ленты подписчиков каналов
  • Зрители должны иметь возможность поменять качество видео при просмотре

Нефункциональные требования

Решение должно обладать следующими архитектурными характеристиками

  • Система должна обладать высокой доступностью
  • Система должна быть масштабируемой и отказоустойчивой
  • Мы должны по возможности обеспечить низкие затраты на инфраструктуру сервиса

Решение задачи

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

Формализация задачи

В этой задаче мне было бы интересно задать следующие вопросы для уточнения требований (ответы интервьюера я буду отмечать курсивом)

  • Надо ли нам учитывать аутентификацию и авторизацию клиентов?
    Нет, она тут достаточно типовая и лучше не тратить на нее время
  • Можем ли мы использовать внешние сервисы, например, CDN для раздачи контента?
    Да, можем, если обоснуем зачем они нам нужны и как мы будем с ними взаимодействовать. Конкретно по поводу CDN могу сказать, что создание полноценной CDN тянет на отдельную задачу по System Design
  • Будем ли мы глубоко копать в транскодирование видео?
    Нет не будем, так как это уже достаточно специфичный домен и у нас нет цели проверять у всех кандидатов их знания
  • В какие разрешения нам стоит конвертировать видео?
    Допустим в 360, 480, 720, 1080
  • Оригинальное видео сохраняем после всех конвертаций или нет?
    Оригинальное видео будем удалять после всех конвертаций
  • Видео должно становиться доступным у подписчиков когда все разрешения готовы или хотя бы одно?
    Видео будет становиться доступным после того, как все разрешения будут подготовлены
  • Ленты подписчиков формируются умным образом или это просто последние видео, добавленные авторами, на которых мы подписаны
    Пускай ленты в нашем случае будут простыми с сортировкой по времени от самых последних к самым ранним, ленту мы будем получать порциями по 10 элементов
  • Какое количество пользователей у нашего сервиса мы ожидаем?
    DAU (Daily Active Users) нашего сервиса будет 10 mln
  • Наши пользователи географически распределены?
    Да, они расположены в разных регионах
  • Сколько видео в день будут смотреть наши пользователи?
    В среднем 10 видео в день
  • Сколько видео в день будет загружаться
    В среднем пользователи загружают по 0.1 видео в день
  • Какой средний размер видео будет загружаться в наш сервис?
    Средний размер видео будет 300 Mb
  • Как часто пользователи будут запрашивать свой feed с видео?
    В среднем 5 раз в день
  • Сколько храним загруженное видео
    Время хранения не ограничено сверху
  • Количество просмотров видео — 10⁷ * 10 = 10⁸
  • Дневной трафик на download — 10⁸ * 300 Mb = 30 Pb
  • Полоса пропускания на download — 30Pb / 86400 = 43.4 Gbyte/sec
  • Количество загружаемых в день видео — 10⁷ * 0.1 = 10⁶
  • Количество загружаемых в секунду видео — 10⁶ / 86400 ~12 rps
  • Количество запросов feed в секунду — 5*10⁷ / 86400 ~ 580 rps
  • Дневной трафик на upload — 10⁶ * 300 Mb =300 Tb
  • Нам надо будет хранить оригинальные видео пока мы не подготовим видео в нужных разрешениях, потом изначальное видео можно будет удалять — в итоге, нам надо будет
    — относительно постоянное по размеру буферное хранилище для оригинальных видео, возьмем с запасом 1 Pb
    — и постоянно расширяемое хранилище под конвертированное видео, пускай все конвертированное видео в сумме весит как оригинальное — тогда нам надо увеличивать хранилище со скоростью 300 Tb в день

Границы системы

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

  • API для заливки видео автором канала
  • Нотификация автора о том, что видео готово
  • Нотификация подписчиков канала о новом видео
  • API для получения пользователем ленты видео, составленного на основе подписок на каналы
  • Получение бинарного потока с конкретным видео
Рис.1 “Итерация #1 — Границы системы”

Основной поток работы

Здесь проще всего взять основной сценарий и начать с него. В этой задачи это upload video, где создатель видео вызывает наш upload api передавая бинарный файл. Наш API должен сохранить оригинальное видео в blob storage, дальше сохранить задачу на конвертирование видео в нужные разрешения и вернуть клиенту task id.

  • Первый — это notification worker и он отправляет нотификации о готовности видео автору и его подписчикам через notification service
  • Второй — это feed worker, который будут готовить ленты для подписчиков и складывать ее в feed database
Рис.2 “Итерация #2 — Основной поток работы”

Концептуальная схема системы

Здесь нам надо поговорить про

  • Классы кубиков, из которых состоит система
  • Модели данных, которые хранятся в этих кубиках и/или путешествуют между ними
Рис.3 “Оптимизированная часть приема задач на загрузку”
  • У нас есть stateless сервисы, например, workers, api
  • У нас есть blob storage для хранения бинарных данных
  • У нас есть message queue для хранения сообщений
  • У нас есть несколько баз данных для
    — хранения метаинформации по загруженным видео
    — хранения информации по лентам подписок
  • У нас есть внешние сервисы, которыми мы просто пользуемся
    — это follower service, который мы используем для получения информации о подписках
    — это notification service, который мы используем для отправки нотификаций авторам загружаемого видео и его подписчикам
    — это cdn, который мы используем для раздачи бинарных данных видео уже конечным пользователям
Рис.4 ”Итерация #3 — Концептуальная схема”

Реальная схема и масштабирование под нагрузку

Относительно реальной схемы пробежимся по порядку

Дополнительные вопросы

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

P.S.

Обычно мы стараемся оставить порядка 5 минут на вопросы кандидата, чтобы он мог спросить интервьюеров все что он хочет. Самые частые вопросы, которые я слышал

  1. “Зачем вы задаете такие задачи?”
  2. “Действительно ли придется внутри решать похожие задачи?”
  3. “В какую команду или в какой продукт меня смотрят?”
  4. “Как выглядит процесс работы внутри команд?”
  1. На первый вопрос я подробно отвечал в статье в части “Зачем мы проверяем навыки дизайна систем?” и если сократить, то мы идем в сторону децентрализации принятия архитектурных решений — инженеры в командах должны сами уметь в проектирование систем
  2. Ответ на этот вопрос зависит от команды, куда попадет кандидат и сложности их задач, но с учетом ответа из первого пункта кажется, что архитектурные решения придется принимать в любом случае
  3. Это интересный вопрос, но на этапе system design interview на него не ответить, так как мы нанимаем в компанию, а не в команду — это значит, что узнать какая именно команда пригласит кандидата на финальное интервью можно будет только после прохождения всех технических секций
  4. И этот вопрос сильно зависит от финальной команды, в которую попадет кандидат, но у нас дефолтом являются agile подходы с выраженным продуктовым подходом в управлении как бизнес-продуктами, так и командами разработки

P.P.S

Внимательные читатели заметят, что мы не все изначальные требования выполнили в рамках нашей системы — обычно в реальном мире так и бывает и никто и никогда в рамках часового интервью не успевает закрыть все вопросы. Так что и в этой статье я хотел показать, что “не боги горшки обжигают” и что хорошая система сейчас лучше, чем идеальная когда-то:)

Рис.5 “Финальная схема со всеми итерациями”

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.