CDN para live streaming: como escalar para 10 mil espectadores com qualidade

Escalar uma API REST para 10 mil usuários simultâneos é relativamente simples: adicione instâncias, coloque um load balancer na frente e pronto. Escalar vídeo ao vivo para 10 mil espectadores simultâneos é um problema completamente diferente, e a maioria das soluções genéricas falha justamente aqui.

Neste artigo, explicamos como CDNs especializadas em vídeo ao vivo funcionam, por que são diferentes de CDNs tradicionais e como a EdTurb garante qualidade de imagem e baixo buffering mesmo em grandes picos de audiência.

CDN para live vs CDN para VOD, qual é a diferença?

Uma CDN tradicional funciona bem para conteúdo estático: um arquivo de vídeo é enviado uma vez ao servidor de origem, replicado para os nós de borda e servido em cache para todos os usuários que o solicitarem. A lógica é simples e eficiente.

Streaming ao vivo não tem arquivo pré-existente. O conteúdo é gerado em tempo real, em segmentos de poucos segundos, e cada nó de borda precisa buscar os segmentos mais recentes do servidor de origem conforme eles são produzidos. Isso cria três desafios únicos:

• ▸Cache de curtíssima duração: segmentos HLS de 1 segundo ficam obsoletos rapidamente, o nó precisa de uma política de TTL muito agressiva.
• ▸Propagação em tempo real: novos segmentos precisam chegar ao nó de borda antes que os players os solicitem, ou o buffer fica vazio.
• ▸Thundering herd: quando um pico súbito de viewers ocorre (ex: um influencer anuncia ao vivo), todos os players solicitam o mesmo segmento ao mesmo tempo no nó de borda.

Como funcionam os nós de borda (PoPs)

A rede de distribuição da EdTurb é composta por Pontos de Presença (PoPs, Points of Presence) distribuídos geograficamente. Quando um espectador inicia a reprodução, o sistema resolve automaticamente o PoP mais próximo com base em latência de rede, não apenas distância geográfica.

O fluxo de um segmento funciona assim:

• ▸O streamer envia o vídeo via RTMP/SRT para o servidor de ingest da EdTurb.
• ▸O servidor transcodifica o stream em múltiplas qualidades (360p, 720p, 1080p).
• ▸Os segmentos LL-HLS são empurrados proativamente para os PoPs configurados antes dos players solicitarem.
• ▸O player do espectador busca segmentos do PoP mais próximo, sem passar pelo servidor de origem.

Streaming Adaptativo (ABR) e qualidade de vídeo

Adaptive Bitrate Streaming (ABR) é a técnica que permite ao player alternar dinamicamente entre qualidades com base na largura de banda disponível do espectador. Em vez de um único arquivo de vídeo, o servidor oferece múltiplas renditions:

# Exemplo de manifesto HLS com ABR
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=500000,RESOLUTION=640x360
360p/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720
720p/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8

O player monitora continuamente a taxa de download e troca de rendition automaticamente, sem buffering visível para o espectador. Em conexões instáveis (3G, Wi-Fi fraco), o player cai para 360p; em conexões rápidas, sobe para 1080p.

A EdTurb gera as renditions automaticamente com base no perfil de encoding configurado para a sala. Você não precisa gerenciar transcodificação manualmente.

Como a EdTurb gerencia a escala automaticamente

Elasticidade no ingest

O servidor de ingest da EdTurb escala horizontalmente conforme o número de streams simultâneos cresce. Para a maioria dos casos de uso (uma live por vez), isso é transparente. Para plataformas com centenas de streams simultâneos, a EdTurb oferece capacidade dedicada.

Roteamento inteligente de espectadores

O DNS da EdTurb usa anycast para rotear cada espectador ao PoP com menor latência de rede no momento da conexão. Se um PoP ficar sobrecarregado, o tráfego é redistribuído automaticamente para o próximo mais próximo.

Monitoramento de saúde em tempo real

Você pode consultar métricas de escala via API durante o evento:

const health = await client.analytics.getStreamHealth({
  roomId: "<room-id>",
});

console.log(health.viewerCount);        // 8432 espectadores ao vivo
console.log(health.cdnBandwidthMbps);   // 18.4 Gbps distribuídos
console.log(health.bufferRatio);         // 0.3% dos players em buffering
console.log(health.qualityDistribution);
// { "1080p": 0.62, "720p": 0.31, "360p": 0.07 }

Preparando sua transmissão para grandes eventos

Para eventos com audiência esperada acima de 5 mil viewers simultâneos, siga estas práticas:

1. Pre-warming da CDN

Notifique a EdTurb sobre eventos de grande escala com antecedência. Isso permite pré-alocar capacidade nos PoPs das regiões com maior concentração esperada de audiência:

await client.events.schedule({
  roomId: "<room-id>",
  expectedViewers: 8000,
  startAt: "2025-06-15T19:00:00Z",
  regions: ["sa-east-1", "us-east-1"],  // regiões prioritárias
});

2. Stream de backup

Configure um ingest secundário para failover automático caso o stream principal tenha problemas de conectividade:

const room = await client.rooms.create({
  name: "grande-evento",
  redundancy: {
    enabled: true,
    failoverThresholdSeconds: 5,  // troca para backup após 5s sem sinal
  },
});

console.log(room.ingestUrl);        // URL principal
console.log(room.backupIngestUrl);  // URL de backup

3. Qualidade máxima adaptada ao público

Para audiências muito grandes e geograficamente diversas, considere limitar a resolução máxima a 720p. Isso reduz o custo de CDN e garante que espectadores em conexões medianas tenham uma boa experiência sem buffering.

• ▸Use pre-warming para eventos com mais de 5 mil viewers esperados.
• ▸Configure stream de backup para eventos críticos (lançamentos, aulas ao vivo pagas).
• ▸Monitore buffer_ratio em tempo real, acima de 2% indica necessidade de ajuste.
• ▸Considere distribuição geográfica ao escolher horários: evite picos de rede regionais.
• ▸Para eventos recorrentes (ex: aulas semanais), analise as métricas históricas para prever capacidade.