Streaming de Vídeo

"Projete uma plataforma de vídeo como o YouTube: criadores enviam vídeos, a plataforma os processa e milhões de espectadores assistem sem travar, em qualquer dispositivo e qualquer rede."

Vídeo é o caso em que banda, e não requisições, é o gargalo. Um redirecionamento tem 500 bytes; um minuto de vídeo HD tem dezenas de megabytes. Quase toda decisão de design decorre disso: os espectadores nunca tocam seus servidores (uma CDN entrega os bytes), os uploads nunca passam pelos seus servidores (vão direto para o object storage), e o trabalho pesado de CPU (transcodificação) é um pipeline em lote de workers que pode levar minutos. As partes interessantes são o pipeline, o streaming com bitrate adaptativo e a economia do tráfego de saída (egress).

O BoxOffice usa vídeo em toda página de evento — trailers de artistas, tours pelos locais, replays de shows transmitidos ao vivo. Seu volume é pequeno perto do YouTube, mas a arquitetura é a mesma, e no dia em que um artista anuncia uma turnê com um vídeo, é a CDN que mantém a página do evento de pé.

1. Esclarecer os requisitos

(roteiro de entrevista)

Requisitos funcionais

1. Criadores enviam vídeos (até alguns GB) pela web e pelo celular, e acompanham o progresso do processamento.
2. A plataforma transcodifica cada upload em várias resoluções e formatos, com miniaturas.
3. Espectadores assistem com reprodução suave que se adapta à conexão; podem avançar e voltar.
4. Metadados básicos: título, descrição, dono; contagem de visualizações.

Requisitos não funcionais

Fora do escopo (diga explicitamente)

Recomendações, comentários, monetização/anúncios, transmissão ao vivo (um follow-up), detecção de direitos autorais (cite como etapa assíncrona), detalhes de DRM.

2. Estimativas de guardanapo (back-of-the-envelope)

# Video streaming: assumptions (illustrative; prices are placeholders, not quotes)
dau          = 50_000_000
watch_min    = 30            # minutes watched per viewer per day
bitrate_mbps = 3.0           # average delivered bitrate
peak_factor  = 3
uploads_day  = 500_000
video_min    = 10            # average upload duration
source_mbps  = 10            # bitrate of the uploaded original
ladder_mbps  = 10.6          # sum of all rendition bitrates (240p..1080p)
renditions   = 6
cdn_hit      = 0.95          # share of bytes served from CDN caches
usd_per_gb   = 0.01          # illustrative blended CDN price

egress_pb_day  = dau * watch_min * 60 * bitrate_mbps / 8 / 1e9
concurrent     = dau * watch_min / 1_440                   # Little's Law: viewers watching now
peak_streams   = concurrent * peak_factor
peak_tbps      = peak_streams * bitrate_mbps / 1e6
origin_tb_day  = egress_pb_day * 1e3 * (1 - cdn_hit)
raw_tb_day     = uploads_day * video_min * 60 * source_mbps / 8 / 1e6
encoded_tb_day = uploads_day * video_min * 60 * ladder_mbps / 8 / 1e6
encode_workers = uploads_day * video_min * renditions / 1_440   # 1 rendition-minute per worker-minute
cdn_usd_day    = egress_pb_day * 1e6 * usd_per_gb

rows = [
    ("egress_pb_day", egress_pb_day, "PB/day"), ("concurrent", concurrent, "streams"),
    ("peak_streams", peak_streams, "streams"), ("peak_tbps", peak_tbps, "Tbit/s"),
    ("origin_tb_day", origin_tb_day, "TB/day"), ("raw_tb_day", raw_tb_day, "TB/day"),
    ("encoded_tb_day", encoded_tb_day, "TB/day"), ("encode_workers", encode_workers, "workers"),
    ("cdn_usd_day", cdn_usd_day, "USD/day"),
]
print("| quantity | value | unit |\n|---|---:|---|")
for name, value, unit in rows:
    v = f"{value:,.0f}" if abs(value) >= 100 else f"{value:,.2f}"
    print(f"| `{name}` | {v} | {unit} |")

O que os números dizem:

• Os espectadores puxam ~34 PB por dia, ~9 Tbit/s no pico. Nenhum data center serve isso a partir de alguns servidores. ⇒ a CDN entrega os bytes, perto dos espectadores; nossa origem só deve ver as faltas.
• Mesmo com 95% de acerto na CDN, a origem (object storage) serve ~1,7 PB/dia ⇒ um origin shield (um cache intermediário) entre as bordas da CDN e o armazenamento, para que uma falta em 300 pontos de presença vire uma única busca.
• Os uploads acrescentam ~375 TB/dia de originais e ~400 TB/dia de renditions codificadas ⇒ object storage com regras de ciclo de vida (mover renditions antigas e pouco vistas para camadas mais frias; manter originais em armazenamento de arquivo para recodificar depois).
• A transcodificação precisa da ordem de ~20 mil workers de codificação ocupados o dia todo (com essa velocidade ilustrativa). ⇒ workers elásticos movidos por fila, ideais para capacidade preemptível/spot barata.
• Com um preço ilustrativo de 1 centavo por GB, a entrega custa centenas de milhares de dólares por dia: cada ponto percentual de bitrate economizado com codificação melhor, ou de taxa de acerto do cache, é dinheiro de verdade. ⇒ as otimizações "chatas" (escolha de codec, codificação por título) são arquitetura.

3. API

POST /v1/videos                                   → 201 {videoId, uploadId, partSize, partUrls[]}
     {"title": "Rock in Rio 2027 — official trailer", "sizeBytes": 734003200, "contentType": "video/mp4"}
PUT  <pre-signed partUrl #n>   (bytes of part n, straight to object storage) → 200 ETag
POST /v1/videos/{videoId}/complete  {"parts": [{"n": 1, "etag": "…"}, …]}   → 202 {status: PROCESSING}
GET  /v1/videos/{videoId}                          → 200 {status: PROCESSING|READY|FAILED,
                                                          progress, manifestUrl, thumbnails[]}

GET  https://cdn.example/vod/{videoId}/master.m3u8         (manifest, from the CDN)
GET  https://cdn.example/vod/{videoId}/720p/seg_00042.m4s  (segment, from the CDN)

POST /v1/events/playback   [{"videoId": "…", "type": "start|heartbeat|rebuffer|end", "ts": …}]  → 202

• A aplicação nunca repassa bytes de vídeo: ela assina URLs. O object store e a CDN fazem o trabalho pesado.
• Upload multipart: o arquivo é dividido em partes (ex.: 8–64 MB) enviadas em paralelo e repetidas de forma independente; o complete as junta. Uma conexão que cai custa uma parte, não o arquivo inteiro.
• Os beacons de reprodução são agrupados e assíncronos: alimentam as contagens de visualização e as métricas de qualidade (tempo de início, travamentos).

4. Modelo de dados

CREATE TABLE video (
    video_id     UUID PRIMARY KEY,
    owner_id     BIGINT      NOT NULL,
    title        TEXT        NOT NULL,
    status       TEXT        NOT NULL,   -- UPLOADING | PROCESSING | READY | FAILED | BLOCKED
    duration_s   INT,
    source_key   TEXT,                   -- raw/{video_id}/source.mp4
    manifest_key TEXT,                   -- vod/{video_id}/master.m3u8
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE transcode_task (
    video_id   UUID,
    task       TEXT,                     -- 'split', 'encode:720p:chunk-007', 'package', 'thumbs'
    status     TEXT NOT NULL,            -- PENDING | RUNNING | DONE | FAILED
    attempts   INT  NOT NULL DEFAULT 0,
    output_key TEXT,
    PRIMARY KEY (video_id, task)
);

# Object storage layout
raw/{video_id}/source.mp4                    original, kept (archive tier after 30 days)
vod/{video_id}/master.m3u8                   master manifest (lists renditions)
vod/{video_id}/{rendition}/index.m3u8        media playlist per rendition
vod/{video_id}/{rendition}/seg_00001.m4s     ~4 s segments (CMAF fragments)
thumbs/{video_id}/{n}.jpg

5. Design de alto nível

flowchart LR
    cr([Criador]) --> api["API de vídeo"]
    api --> meta[("Metadados<br/>SQL")]
    cr -. "partes via<br/>URLs pré-assinadas" .-> raw[("Object store<br/>raw/")]
    raw -. upload concluído .-> q[["Fila de transcodificação"]]
    q --> w["Workers de transcodificação<br/>divide · codifica · empacota"]
    w --> vod[("Object store<br/>vod/")]
    w --> meta
    v([Espectador]) --> cdn["Borda da CDN"]
    cdn --> shield["Origin shield"]
    shield --> vod
    v -. beacons de reprodução .-> an["Analytics<br/>visualizações, QoE"]

Do upload à primeira reprodução:

sequenceDiagram
    autonumber
    participant C as App do criador
    participant A as API de vídeo
    participant S as Object store
    participant Q as Fila
    participant W as Workers
    participant V as Espectador
    participant E as CDN
    C->>A: POST /videos (tamanho, tipo)
    A-->>C: videoId + URLs pré-assinadas das partes
    C->>S: PUT das partes em paralelo (repete as que falham)
    C->>A: POST /complete
    A->>Q: enfileira split(videoId)
    Q->>W: divide em pedaços, enfileira tarefas de codificação
    W->>S: grava 240p/360p primeiro → status READY
    W->>S: grava 720p/1080p depois, atualiza o manifesto
    V->>E: GET master.m3u8, depois os segmentos
    E->>S: falta → busca uma vez via shield
    E-->>V: segmentos (em cache para todo mundo)

6. Aprofundamentos (deep dives)

6.1 Uploads que contornam a aplicação

• URLs pré-assinadas: a API autoriza o upload e devolve URLs que permitem ao cliente fazer PUT direto no object store por alguns minutos. Os servidores de aplicação lidam com kilobytes de JSON, nunca com gigabytes de vídeo (object storage).
• Multipart e retomável: as partes sobem em paralelo e são repetidas individualmente; o cliente guarda o uploadId para retomar depois de o app ser fechado. Uploads incompletos são limpos por uma regra de ciclo de vida.
• Integridade e segurança: um checksum por parte; depois do complete, uma etapa assíncrona valida o contêiner, procura malware e roda verificações de conteúdo antes de publicar.
• Upload perto do usuário: object stores oferecem ingestão acelerada/na borda; para um público global, envie para a região mais próxima e replique.

6.2 Transcodificação como um DAG de tarefas

Codificar um vídeo de 2 horas numa máquina só leva tempo demais. Divida, codifique os pedaços em paralelo e junte de volta:

flowchart LR
    src["source.mp4"] --> split["Divide em<br/>pedaços de ~10 s<br/>(nos keyframes)"]
    split --> e1["codifica 240p…1080p<br/>pedaço 1"]
    split --> e2["codifica 240p…1080p<br/>pedaço 2"]
    split --> e3["codifica 240p…1080p<br/>pedaço N"]
    src --> th["Miniaturas"]
    src --> au["Faixas de áudio"]
    e1 --> pkg["Empacota<br/>HLS / DASH (CMAF)"]
    e2 --> pkg
    e3 --> pkg
    au --> pkg
    pkg --> pub["Publica<br/>manifesto + status"]
    th --> pub

• Movido por fila: cada nó do DAG é uma mensagem de tarefa; um pequeno orquestrador (ou um motor de workflow) enfileira uma tarefa quando suas entradas estão prontas (trabalho assíncrono).
• Tarefas idempotentes: uma tarefa grava numa chave determinística (vod/{id}/720p/chunk-007) — rodá-la duas vezes produz o mesmo objeto, então retentativas e entregas duplicadas são inofensivas.
• Priorize: codifique as resoluções baixas primeiro e publique assim que existirem; os degraus mais altos e os codecs caros (AV1) vêm depois. Criadores populares ou os trailers oficiais do BoxOffice podem ir para uma fila de alta prioridade.
• Elástico e barato: codificar é limitado por CPU/GPU e pode ser reiniciado — rode em instâncias preemptíveis com autoscaling; uma tarefa interrompida é simplesmente repetida.

6.3 Streaming com bitrate adaptativo

Cada vídeo é codificado numa escada de renditions, cada uma cortada em segmentos curtos (2–6 s). O player baixa um manifesto que lista as renditions, mede sua vazão e seu buffer e escolhe a rendition do próximo segmento — subindo ou descendo sem parar (HLS, MPEG-DASH).

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2"
360p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8

• Comece baixo, suba rápido: o primeiro segmento vem de um degrau baixo para a reprodução começar em menos de 2 s; o player sobe conforme o buffer enche.
• Codificação por título: um desenho animado precisa de bem menos bits do que um show com confete e luzes estroboscópicas para a mesma qualidade visual. Analisar cada vídeo e escolher sua própria escada (a "per-title encode optimization" da Netflix) economiza uma boa parte da banda em conteúdo simples.
• Codecs: H.264 toca em todo lugar; HEVC e AV1 entregam a mesma qualidade com bem menos bits, mas custam muito mais CPU para codificar e não são suportados em todo dispositivo. Codifique os codecs caros só para vídeos com visualizações suficientes para pagar o custo.

6.4 Entrega: CDN, shield e a cauda longa

• As bordas da CDN guardam manifestos e segmentos perto dos espectadores. Os segmentos são imutáveis (conteúdo novo = chave nova), então podem ficar em cache por muito tempo sem invalidação (DNS e CDN).
• Origin shield: uma camada de cache regional na frente do object store; todas as bordas buscam no shield, que busca na origem no máximo uma vez por objeto — essencial para um vídeo que viraliza minutos após o upload.
• A popularidade é uma cauda longa: uma pequena fração dos vídeos recebe a maioria das visualizações. Empurre (pré-posicione) a cabeça para as bordas antes da demanda — ex.: o trailer do BoxOffice antes do anúncio de uma turnê — e deixe a cauda longa ser puxada sob demanda, aceitando um primeiro início mais lento.
• Multi-CDN e caches dentro dos provedores de internet (como a Netflix faz com o Open Connect) são os próximos passos em escala muito grande, por custo e resiliência.
• As contagens de visualização vêm dos beacons de reprodução, por um stream, até contadores agregados, deduplicados por sessão e filtrando bots; contagens exatas em tempo real não são necessárias.

7. Gargalos, modos de falha e trade-offs

Os trade-offs para dizer em voz alta: custo de codificação vs. custo de entrega (gastar CPU uma vez para economizar banda em cada visualização — só vale para vídeos que serão vistos), tempo para publicar vs. completude (resoluções baixas primeiro), e empurrar vs. puxar para a borda (pré-posicionar a cabeça, puxar a cauda).

8. Experimente no playground

O cenário video-streaming tem o object store, uma CDN na frente dele e uma fila de workers de transcodificação alimentada pelos uploads.

Abrir o playground completo

9. Perguntas de follow-up que o entrevistador faz

10. Rubrica de autoavaliação

Relacionados: DNS e CDN, Armazenamento especializado (object stores), Trabalho assíncrono, FinOps, Hands-on 7 (filas e workers).

Como se conecta

Quais aulas este caso testa? Cada ramo é uma aula cujas ideias o design usa (azul), com os componentes da paleta em que elas aparecem (verde):

flowchart LR
    CASE(["Video streaming"]) --> EST["Estimation<br/>egress bandwidth dominates"]:::tech
    CASE --> DB["Databases<br/>object store, pre-signed uploads"]:::tech
    CASE --> CMP["Compute<br/>transcoding DAG, idempotent workers"]:::tech
    CASE --> MSG["Messaging<br/>transcode queue"]:::tech
    CASE --> EDG["Edge<br/>CDN, origin shield, ABR segments"]:::tech
    CASE --> FIN["Cloud-native<br/>FinOps: cost of egress"]:::tech
    DB -.-> k1["objstore · sql"]:::comp
    CMP -.-> k2["worker"]:::comp
    MSG -.-> k3["queue"]:::comp
    EDG -.-> k4["cdn · analytics"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Aulas que ele testa: Borda — DNS e CDN · Bancos de dados — especializados (armazenamento de objetos) · Compute — trabalho assíncrono · Mensageria — filas e pub/sub · Cloud-native — FinOps · Hands-on 7. Componentes da paleta: cdn · objstore · queue · worker · sql · analytics. Cenários: video-streaming, cdn-static.

Referências

• XU, A. System Design Interview — An Insider's Guide, vol. 1, cap. 14 "Design YouTube"¹.
• A especificação do HTTP Live Streaming (HLS)² e o MPEG-DASH³.
• A codificação por título da Netflix⁴.