Как спроектировать видеоплатформу вроде YouTube: системный дизайн

Зачем разбирать YouTube

Снаружи видеоплатформа выглядит просто: автор загружает ролик, зритель нажимает Play. Под капотом — хранение огромных объёмов данных, адаптивный стриминг, глобальная доставка и постоянный баланс между качеством и стоимостью трафика. Тот же каркас полезен для Netflix-подобных сервисов, образовательных платформ и корпоративных медиатеков.

Ниже — сжатый, практичный системный дизайн: как сузить scope, оценить нагрузку, собрать high-level схему и углубить ключевые места (транскодинг, скорость загрузки, безопасность, CDN-затраты, ошибки).

1. Сужаем задачу

За 45–60 минут интервью или на старте MVP нельзя спроектировать «весь YouTube». Зафиксируйте договорённости:

• Must-have: быстрая загрузка и плавный просмотр.
• Клиенты: web, mobile, Smart TV.
• Масштаб (пример): 5 млн DAU.
• Контент: малые и средние ролики, максимум ~1 ГБ на файл.
• Форматы: большинство распространённых; шифрование — да.
• Инфраструктура: разумно опираться на облако (object storage + CDN), а не строить всё с нуля.

Фокус архитектуры: быстрый upload → обработка → адаптивный streaming, высокая доступность и контролируемая стоимость.

2. Оценка «на салфетке»

Допущения для прикидки:

• 5 млн DAU, ~5 просмотров на пользователя в день.
• 10% пользователей загружают 1 видео в день.
• Средний размер исходника ~300 МБ.

Хранение в день: 5 млн × 10% × 300 МБ ≈ 150 ТБ новых исходников — без учёта нескольких закодированных версий.

CDN: если почти весь просмотр идёт с CDN, трафик быстро становится главным пунктом расходов. При грубой оценке порядка $0.02/ГБ (как ориентир публичных прайсов) одни только просмотры могут выходить на сотни тысяч долларов в день на таком масштабе. Вывод: CDN обязателен для latency, но без политики «что кэшировать» экономика не сходится.

3. High-level архитектура

Систему удобно разделить на три контура:

1. Клиенты — web / mobile / TV.
2. CDN — отсюда идёт сам видеопоток к зрителю.
3. API-слой — всё остальное: метаданные, выдача URL загрузки, рекомендации, аккаунты, плейлисты и т.д.

Видео не гоняют через API-серверы на просмотре: API отвечает за оркестрацию и метаданные, байты отдаёт CDN/edge.

Почему не писать свой blob storage и CDN в первой версии? Для большинства команд это дорого и долго. Даже крупные игроки опираются на облако или партнёрские сети. На интервью важнее выбрать правильные блоки, чем пересказывать внутренности S3.

Загрузка видео

Параллельно работают два процесса:

• A. Загрузка файла в object storage (исходники).
• B. Запись метаданных (название, размер, формат, автор, статус).

Типовой пайплайн после upload:

1. Файл попадает в original storage.
2. Transcoding workers кодируют в нужные битрейты/контейнеры (HLS, DASH и др.).
3. Готовые файлы уходят в transcoded storage и раскатываются на CDN.
4. Событие «готово» попадает в очередь; completion handlers обновляют БД метаданных и кэш.
5. Клиент получает сигнал, что ролик доступен к просмотру.

Вокруг этого: load balancer, шардированная metadata DB, кэш метаданных/пользователей.

Стриминг

Скачивание целиком и streaming — разное. При стриминге клиент подгружает сегменты и может стартовать сразу. Протоколы (ориентиры): MPEG-DASH, Apple HLS, Smooth Streaming, HDS. Важно не зазубрить названия, а понимать: протокол определяет, как клиент выбирает качество и какие плееры совместимы.

Зритель почти всегда получает поток с ближайшего edge CDN — это главный способ удержать низкую задержку.

4. Транскодинг глубже

Исходный файл с телефона плохо подходит для массового просмотра: он тяжёлый, не везде совместим, не адаптируется под слабый канал. Поэтому нужны несколько представлений (разрешения, кодеки, битрейты).

• Контейнер (.mp4, .mov, .avi…) — «коробка» с видео, аудио и метаданными.
• Кодек (H.264, VP9, HEVC…) — сжатие с сохранением приемлемого качества.

Пайплайн удобно моделировать как DAG (направленный ациклический граф задач): inspection → split A/V → encodings → thumbnails → watermark. Так разные авторы получают разные сценарии обработки, а независимые шаги идут параллельно.

Практичная схема воркеров:

• Preprocessor — режет поток на GOP/сегменты, строит DAG по конфигу, кэширует куски для ретраев.
• DAG scheduler — раскладывает граф на стадии и задачи.
• Resource manager — очереди задач/воркеров/running + планировщик, который сматчит приоритетную задачу с подходящим воркером.
• Task workers — encoding, audio, thumbnail, watermark.
• Temporary storage — метаданные в памяти/быстром store, сегменты в blob; после успеха чистим.

5. Оптимизации

Скорость загрузки

• Резать файл на чанки (GOP) и грузить параллельно с возможностью resume.
• Держать upload-центры ближе к пользователям (часто через точки присутствия CDN/регионы облака).
• Развязывать шаги message queue: download → encode → publish не должны быть жёсткой синхронной цепочкой.

Безопасность

• Pre-signed URL (или SAS в Azure): клиент получает временный URL на запись в bucket, API не проксирует гигабайты.
• Защита контента: DRM (FairPlay / Widevine / PlayReady), AES + политика доступа, watermark.

Стоимость CDN

Просмотры обычно long-tail: немного роликов дают почти весь трафик. Отсюда:

1. Горячий контент — с CDN; холодный — с собственных/дешёвых origin-серверов.
2. Для непопулярного не хранить десятки качеств заранее; короткие ролики можно кодировать on-demand.
3. Региональная популярность: не зеркалить всё по всему миру.
4. На очень большом масштабе — свой CDN и партнёрства с ISP (как у крупных стримеров).

Любая экономия должна опираться на реальные паттерны просмотра, а не на интуицию.

6. Обработка ошибок

• Восстановимые: сбой сегмента/воркера — несколько ретраев, затем ошибка клиенту.
• Невосстановимые: битый контейнер — остановить пайплайн, вернуть понятный код.

Чеклист по компонентам: retry upload; split на сервере, если старый клиент не умеет; retry encode; пересобрать DAG; реплика очереди resource manager; переназначить task worker; API stateless → другой инстанс; кэш/БД — репликация, failover master/slave.

7. Что обсудить, если осталось время

• Горизонтальный scale API (stateless) и БД (репликация, шардирование).
• Live streaming: похожий контур upload/encode/play, но жёстче latency, меньше «тяжёлого» параллелизма пакетами, ошибки нельзя лечить долгими ретраями.
• Модерация и takedown (копирайт, жалобы) — на upload и по флагам пользователей.

Итог для продукта

Рабочая формула видеохостинга: object storage + асинхронный транскодинг + CDN + тонкий API вокруг метаданных. Дальше — параллельная загрузка, очереди, политика «горячего» контента и защита прав. Этот каркас масштабируется от MVP медиатеки до глобального сервиса — меняется глубина автоматизации и география edge.

Если проектируете видеопоток, медиатеку или образовательную платформу — обсудите архитектуру с Softverno или оцените объём в калькуляторе. Связанные услуги: веб-разработка, MVP.