Designing a Live Streaming Platform

Live streaming requires ultra-low latency ingest, real-time transcoding, and massive fan-out to viewers.

Requirements

• Streamers broadcast at 1080p/60fps
• Viewers watch with <5s latency
• 100K concurrent viewers per stream
• Live chat
• Stream recording

Ingest Pipeline

Streamer → RTMP (push) → Ingest Servers
                             ↓
                    Transcoding Service
                    (360p, 720p, 1080p)
                             ↓
                    HLS Segments (2s chunks)
                             ↓
                    CDN Edge Servers

Protocols

RTMP:   Streamer → Server (low latency push)
HLS:    Server → Viewer (adaptive, 3-8s latency)
WebRTC: Ultra-low latency (<500ms) for video calls
SRT:    RTMP replacement, better packet loss handling

Latency Ladder

WebRTC (LL-WebRTC): <500ms  — video conferencing
LL-HLS / LHLS:     1-3s    — interactive streaming
HLS / DASH:        3-8s    — standard streaming

Transcoding at Scale

Ingest stream → Split into GOP chunks
                     ↓
          Parallel GPU transcoding workers
          (FFmpeg, AWS MediaConvert)
                     ↓
          Multiple quality tiers → S3/CDN

Chat System

• WebSocket per viewer connection to Chat Server
• Messages fan-out via Redis Pub/Sub
• Moderation: Word filters + ML hate speech detection
• Slow mode: Rate limit messages per user

Viewer Scaling

100K viewers × stream requests every 2s
= 50K req/sec per stream
→ CDN handles 99%+ of load
→ Origin only serves initial manifest + new segments

Stream Recording

All HLS segments archived to S3 → VOD available immediately after stream ends.

Conclusion

Live streaming is a CDN-first architecture. RTMP ingest, GPU transcoding, and HLS delivery through edge CDN is the proven stack.