Видеохостинг ломается не на экране плеера, а там, где нужно принять огромный поток загрузок, пережить тяжёлую обработку и потом многократно дешевле отдать тот же ролик миллионам зрителей.
Глава помогает собрать в одну систему приём видео, очередь транскодирования, хранение исходных и готовых файлов, публикацию в ленты и доставку через сеть доставки контента.
В интервью и инженерных обсуждениях этот кейс полезен тем, что заставляет отдельно объяснить тяжёлый путь записи, горячий путь чтения, стратегию раздачи в ленты и цену медиатрафика.
Тяжёлый путь записи
Загрузка, проверка и обработка ролика не должны тормозить публикацию и не должны мешать пути просмотра, который живёт по совсем другому профилю нагрузки.
Очередь транскодирования
Асинхронная обработка нужна, чтобы растянуть CPU-нагрузку по времени, переживать всплески загрузок и отдельно масштабировать воркеры.
Горячий путь чтения
Лента, метаданные и доставка сегментов обязаны отвечать быстро даже тогда, когда свежий ролик внезапно становится массовым.
Цена медиатрафика
Основные расходы рождаются не только в дисках, но и в сетевой выдаче, прогреве кэша, количестве вариантов качества и повторных чтениях из исходного хранилища.
Публичное интервью на C++ Russia 2022 хорошо показывает, что сложность видеохостинга начинается далеко за плеером. Система должна принять пользовательский ролик, запустить , быстро обновить ленты и затем отдать тот же контент миллионам зрителей через .
Запись интервью
Полная запись публичного интервью доступна на YouTube. Ценность здесь не в финальной схеме, а в том, как кандидат рассуждает: где уточняет требования, где выбирает компромисс и где отказывается от лишнего.
Смотреть на YouTubeПостановка задачи
Лента видеохостинга
Нужно спроектировать сервис, в котором авторы загружают видео, а зрители смотрят их в хронологической ленте и переключают качество воспроизведения.
На таком масштабе функции продукта быстро упираются в нефункциональные ограничения: , и . Иначе система упрётся либо во время публикации ролика, либо в стоимость его выдачи.
Функциональные
Загрузка видео авторами без долгого ожидания на клиенте.
Публикация ролика в лентах подписчиков после завершения обработки.
Выбор качества воспроизведения от 360p до 1080p.
Хронологическая лента с базовой сортировкой по времени публикации.
Нефункциональные
Доступность: высокая
Просмотр и загрузка должны оставаться рабочими даже при частичных сбоях.
Масштабируемость: горизонтальная
Рост контента и аудитории нельзя упереть в один узел — мощность добавляется новыми машинами.
Устойчивость к отказам: обязательная
Потеря отдельного узла не должна приводить к потере видео или остановке выдачи.
Экономика системы: под контролем
Вычисления, хранилище и сетевая выдача — главные статьи расходов; неконтролируемый рост любой из них делает сервис убыточным.
Грубая оценка нагрузки
Ключевой вывод: здесь доминирует не число запросов, а объём хранения и сетевой выдачи. Поэтому экономику системы определяют количество вариантов качества, стратегия кэширования и стоимость медиатрафика.
Высокоуровневая архитектура
Архитектура разделяет — приём файла, проверку и обработку — и — сборку ленты, выдачу метаданных и воспроизведение.
Видеохостинг: общая схема
загрузка, обработка, ленты и выдача видеоКонтур загрузки и обработки
Хранилище и выдача
Контур загрузки и обработки можно масштабировать независимо от контура просмотра. Это позволяет отдельно наращивать число обработчиков, объём кэша и пропускную способность выдачи.
Путь записи и путь чтения
Разбор пути записи и пути чтения
Переключайте сценарий и проигрывайте шаги по очереди.
Путь записи: ключевые шаги
- Создатель загружает исходный файл, а API возвращает `video_id` и статус обработки.
- Видео разбивается на отдельные задачи; обработчики готовят варианты качества 360p, 480p, 720p и 1080p.
- Готовые файлы и сегменты сохраняются в исходном хранилище, а статус публикации обновляется в метаданных.
- После перехода в статус `ready` сервис обновляет ленты подписчиков и отправляет событие о готовности ролика.
Путь чтения: ключевые шаги
- Пользователь открывает ленту, и сервис возвращает список `video_id` по подпискам и персональным сигналам.
- Сервис метаданных отдает HLS/DASH-манифест и список доступных вариантов качества.
- Сеть доставки контента чаще всего выдаёт сегменты из ближайшего к пользователю кэша.
- Если сегмента нет в кэше, сеть доставки контента забирает его из исходного хранилища и сразу прогревает локальную точку выдачи.
Ключевые компоненты
Критические узлы здесь — для тяжёлых задач, для промежуточных и готовых файлов, для сегментов и в метаданных, который нужен плееру для старта.
API загрузки
Принимает бинарные файлы от авторов, проверяет лимиты и кладёт исходный ролик во временное хранилище.
POST /v1/videos → {video_id, upload_url}Очередь задач транскодирования
RabbitMQ или аналог распределяет тяжёлую обработку по обработчикам. Одна загрузка порождает несколько задач — по одной на каждое разрешение.
Обработчики видео
Это обработчики без локального состояния, которые читают задачи из очереди, запускают FFmpeg, собирают варианты качества и легко масштабируются горизонтально под всплеск загрузок.
Хранилище бинарных объектов
S3-совместимое хранилище вроде MinIO или Ceph хранит исходные ролики, готовые файлы и сегменты. Обычно его делят на временный и постоянный контуры.
Хранилище лент
Документная NoSQL-база вроде MongoDB или Cassandra хранит предрассчитанные ленты. Обычно данные шардиются по user_id, а сама лента представляет собой массив ID видео в порядке публикации.
Сеть доставки контента
Сеть доставки контента держит популярные сегменты ближе к зрителю и снимает нагрузку с исходного слоя хранения. Это снижает старта воспроизведения и защищает исходное хранилище от резких всплесков трафика.
Модели данных
Метаданные видео
{
"id": "uuid",
"author_id": "user_123",
"title": "My Video",
"description": "...",
"created_at": "2024-03-15T10:00:00Z",
"status": "ready",
"versions": {
"360p": "s3://videos/uuid/360p.mp4",
"480p": "s3://videos/uuid/480p.mp4",
"720p": "s3://videos/uuid/720p.mp4",
"1080p": "s3://videos/uuid/1080p.mp4"
}
}Лента пользователя
{
"user_id": "user_456",
"feed": [
"video_id_1",
"video_id_2",
"video_id_3",
...
],
"last_updated": "2024-03-15T12:00:00Z"
}Предрассчитанная лента хранит только ID роликов и время последнего обновления, поэтому её дёшево читать и несложно перестраивать.
Стратегии доставки в ленты
Главный продуктовый компромисс здесь — где выполнять : в момент публикации ролика или в момент чтения ленты.
→Раздача при записи (push)
При публикации ролика система сразу добавляет его в ленты подписчиков.
←Сборка при чтении (pull)
Лента собирается по запросу из последних роликов по всем подпискам.
Гибридный подход
Для обычных авторов выгоднее push: он удешевляет чтение. Для очень популярных авторов лучше переключаться на pull или смешанную схему, чтобы не перегружать публикацию миллионами обновлений в момент выхода ролика.
Инфраструктурные сервисы
Балансировщик L4/L7
Распределяет трафик между внешними API и сервисами выдачи.
Обнаружение сервисов
Помогает находить доступные экземпляры сервисов через Consul или etcd.
Автомасштабирование
Увеличивает или уменьшает число обработчиков под фактическую нагрузку.
Мониторинг
Собирает метрики, алерты и логи через Prometheus, Grafana и похожие инструменты.
Ограничение скорости
Защищает систему от злоупотреблений и распределённых атак.
Размыкатель цепи
Включает мягкую деградацию, когда зависимость начинает отвечать нестабильно.
Ключевые выводы из интервью
Разделяйте запись и чтение
Приём и обработка ролика растут по одним законам, а выдача ленты и сегментов — по другим. Эти контуры лучше проектировать и масштабировать отдельно.
Тяжёлые операции отправляйте в очередь
Транскодирование не должно жить в пользовательском запросе. Асинхронная обработка позволяет контролировать нагрузку и отдельно масштабировать обработчики.
Сеть доставки контента обязательна для медиатрафика
При сотнях терабайт нового контента в день без глобального кэша система быстро упрётся в стоимость выдачи и перегрузит исходное хранилище.
Предрассчитывайте то, что читают чаще всего
Готовая лента почти всегда дешевле и быстрее, чем сборка на лету из множества источников при каждом открытии приложения.
Дополнительные материалы
Связанные главы
- Content Delivery Network (CDN) - помогает понять, как глобальное кэширование и распределённая выдача удерживают быстрый старт воспроизведения при большом трафике.
- System Design Interview: An Insider's Guide (краткий обзор) - даёт классический каркас ответа на медиа-кейс: требования, оценки, путь записи, путь чтения и ключевые компромиссы.
- Hacking the System Design Interview (краткий обзор) - углубляет разговор о раздаче в ленты, очередях транскодирования, классах хранения и устойчивости под нагрузкой.
- Примеры задач по системному дизайну - ставит кейс видеохостинга в контекст других систем и помогает сравнивать архитектурные решения между доменами.
- Краткосрочная подготовка к интервью по системному дизайну - показывает, как упаковать решение в интервью: от требований и sizing до схемы, рисков и эволюции системы.