System Design Space
Граф знанийНастройки

Обновлено: 25 марта 2026 г. в 04:52

Лента видеохостинга

medium

Публичное интервью на C++ Russia 2022: транскодирование, fan-out стратегии, CDN и асинхронная обработка.

Лента видеохостинга живет на пересечении тяжелого write path и очень широкого read path: upload, transcoding, moderation, feed generation и delivery через CDN.

Глава помогает связать media processing pipeline, storage tiers, metadata, recommendation или feed serving и playback distribution в одну эволюционирующую систему.

В интервью и инженерных обсуждениях этот кейс полезен тем, что показывает, умеете ли вы разносить асинхронные этапы, защищать hot path чтения и управлять стоимостью media workloads.

Latency Budget

Каждый hop в критическом пути должен иметь чёткий тайм-бюджет и предсказуемое поведение.

Fanout Strategy

Выбор push/pull/hybrid напрямую влияет на масштабируемость и сложность системы.

Session State

Важно учитывать presence, reconnect, ordering и delivery semantics для клиента.

Graceful Degradation

При пиках нагрузок система должна понижать качество сервиса без массового отказа.

На конференции C++ Russia 2022 мы провели публичное System Design интервью с задачей спроектировать ленту видеохостинга — систему, похожую на YouTube. Этот кейс демонстрирует работу с асинхронной обработкой, транскодированием видео и построением персонализированных фидов.

Видеозапись интервью

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

Смотреть на YouTube

Постановка задачи

Video Hosting Feed

Спроектировать приложение, которое позволяет создателям контента загружать видео, а зрителям — просматривать его в хронологической ленте с возможностью выбора качества.

Функциональные

Быстрая загрузка видео для создателей контента.

Публикация видео в лентах подписчиков после завершения обработки.

Выбор качества воспроизведения от 360p до 1080p.

Хронологическая лента с простой сортировкой по времени публикации.

Нефункциональные

Availability: высокая доступность

Сервис просмотра и загрузки должен оставаться доступным при частичных сбоях.

Scalability: горизонтальный рост

Система должна масштабироваться по мере роста контента и аудитории.

Fault tolerance: устойчивость к отказам

Потеря отдельного узла не должна приводить к потере видео или остановке выдачи.

Cost efficiency: контроль инфраструктурных затрат

Архитектура должна эффективно использовать storage, CDN и compute-ресурсы.

Оценка нагрузки (Back of the Envelope)

DAU (Daily Active Users)10 млн
Просмотров в день100 млн
Загрузок видео в день1 млн (~12 RPS)
Запросов ленты в день50 млн (~580 RPS)
Рост хранилища в день~300 ТБ

Ключевой вывод: Основная нагрузка — это хранение и доставка видео, а не количество запросов. Критически важны эффективное использование CDN и оптимизация хранилища.

Высокоуровневая архитектура

Система разделена на два основных пути: Write Path (загрузка и обработка видео) и Read Path (просмотр и лента).

Video Hosting: High-Level Map

ingestion + transcoding + feed + video delivery

Ingestion + Processing Plane

Creator
upload video
API Gateway
auth + routing
Upload API
init upload
Transcode Queue
jobs
Video Workers
HLS/DASH renditions

Storage + Serving Plane

Origin Storage
video files + segments
Metadata DB
video state + manifest
Feed DB
user feeds
Viewer -> Feed API -> CDN
playback path
Общий контур video hosting: ingestion, processing и read-serving разделены по контурам.

Контур upload/transcoding масштабируется независимо от read-serving. Это позволяет отдельно наращивать воркеры обработки и edge capacity CDN.

Read/Write Flow

Read/Write Path Explorer

Переключайте путь и прогоняйте шаги обработки в режиме Play.

1
Creator
upload video
2
Upload API
validate + store temp
3
Queue + Workers
transcode renditions
4
Origin + Metadata
persist files + manifest
5
Feed Update
fan-out + notify
Write path: нажмите Play, чтобы пройти путь от upload до публикации в feed.

Write Path: operational notes

  • Клиент загружает оригинал в upload-контур, после чего API возвращает `video_id` и статус обработки.
  • Видео разбивается на задачи транскодирования; воркеры генерируют несколько quality профилей.
  • Готовые renditions и манифесты публикуются в origin storage, а metadata фиксируется в DB.
  • После статуса `ready` запускается fan-out в feed storage и уведомления подписчикам.

Read Path: operational notes

  • Viewer запрашивает feed, сервис возвращает список `video_id` по подпискам и персональным сигналам.
  • Metadata API отдает playback manifest (HLS/DASH) и доступные разрешения.
  • CDN обслуживает сегменты с edge-узлов; горячий контент почти всегда читается из cache.
  • При cache miss edge запрашивает сегмент в origin storage и сразу прогревает локальный cache.

Ключевые компоненты

Upload API

Принимает бинарные файлы от создателей и сохраняет во временное хранилище.

POST /v1/videos → {video_id, upload_url}

Message Queue (Task Broker)

RabbitMQ или аналог для управления задачами транскодирования. Родительская задача порождает 4 дочерние — по одной на каждое разрешение.

360p
480p
720p
1080p

Video Workers

Stateless воркеры для транскодирования. Читают задачи из очереди, обрабатывают видео (FFmpeg), сохраняют результат в Blob Storage. Легко масштабируются горизонтально.

Blob Storage

S3-совместимое хранилище (MinIO, Ceph) для видеофайлов. Разделено на временное (для загрузки) и постоянное (обработанные видео).

Temp StoragePermanent Storage

Feed Database

Document-oriented NoSQL база (MongoDB, Cassandra) для хранения предрассчитанных лент. Шардируется по user_id. Лента — массив ID видео, отсортированный по времени.

CDN

Критически важен для доставки видео. Кеширует популярный контент на edge-серверах ближе к пользователям. Снижает нагрузку на Blob Storage и уменьшает latency.

Модели данных

Video Meta

{
  "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 Feed

{
  "user_id": "user_456",
  "feed": [
    "video_id_1",
    "video_id_2",
    "video_id_3",
    ...
  ],
  "last_updated": "2024-03-15T12:00:00Z"
}

Предрассчитанная лента — массив ID видео от подписок, отсортированный по времени.

Стратегии построения ленты (Fan-out)

→Fan-out on Write (Push)

При публикации видео добавляем его во все ленты подписчиков.

Быстрое чтение ленты
Проблема с популярными авторами (миллионы подписчиков)

←Fan-out on Read (Pull)

При запросе ленты собираем последние видео от всех подписок.

Простая запись
Медленное чтение при многих подписках

Гибридный подход

Для обычных авторов используем Push (fan-out on write). Для авторов с миллионами подписчиков — Pull при чтении. Это классический компромисс, который использует Twitter/X.

Инфраструктурные сервисы

Load Balancer L4/L7

Распределение трафика между API серверами

Service Discovery

Регистрация и обнаружение сервисов (Consul, etcd)

Auto-scaling

Автоматическое масштабирование воркеров по нагрузке

Monitoring

Метрики, алерты, логирование (Prometheus, Grafana)

Rate Limiting

Защита от abuse и DDoS

Circuit Breaker

Graceful degradation при сбоях

Ключевые выводы из интервью

1

Разделяйте Write и Read пути

Асинхронная обработка видео (Write) и синхронное чтение ленты (Read) имеют разные требования и масштабируются по-разному.

2

Используйте очереди для тяжёлых операций

Транскодирование — ресурсоёмкая операция. Message Queue позволяет управлять нагрузкой и легко масштабировать воркеры.

3

CDN — must have для медиаконтента

При 300 ТБ нового контента в день без CDN система не выживет. Кеширование на edge снижает нагрузку и latency.

4

Предрассчитывайте где возможно

Предрассчитанные ленты (feed) значительно быстрее, чем сборка на лету из множества источников при каждом запросе.

Дополнительные материалы

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки