1Context and scope
Live video is two very different workloads. A few thousand broadcasters push continuous streams that must be transcoded into renditions and packaged into segments within seconds. Millions of viewers pull those segments and a playlist that changes every few seconds, and chat in rooms where one message reaches everyone watching. This design covers ingest, playback manifests and chat at browser scale, based on Twitch’s engineering posts.
2Goals and non-goals
Goals
- 8,000 requests a second: 85% playback, 14% chat messages, 1% ingest.
- Success at least 99%, p99 at most 2 s (ingest requests are slow by nature), Apdex at least 0.90.
- Chat messages fan out to rooms with nothing lost.
Non-goals
- Video bytes: the CDN serves segments.
- Clips, VODs and subscriptions.
- Moderation and bots.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Served at the CDN | 90% of reads | segments are cacheable; manifests less so |
| Manifest cache | 4 GB, 200K streams, 30 s TTL | a live playlist changes every few seconds |
| Chat messages | ≈ 1,120/s | 14% of 8,000, through 64 Kafka partitions |
| Chat fan-out | 256 workers at ≈ 2 ms | publishes each message to its room topic |
| Ingest | ≈ 80/s | each: a transcode (1.5 s, 800 ms CPU) and a segment write |
| Transcoders | 400 slots, 400 vCPU | 80 × 1.5 s = 120 slots busy; 80 × 0.8 = 64 vCPU busy |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Twitch design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.