Twitch's engineering blog describes nearly a hundred points of presence that accept creator streams and forward them over a private backbone to a small number of larger origin data centres holding hundreds to thousands of transcoding servers. Low latency is the product. Why is the transcode not done at the point of presence the streamer connected to, and where would copying this split be a mistake?
Show the full answer Hide the answer
The situation they were in
A live platform has two independent scaling problems. Viewers are many and cheap: a video segment is an object, and a CDN already solves that. Creator uplinks are few and expensive: each is a long-lived session arriving over whatever consumer connection the creator happens to have, and each must become an adaptive bitrate ladder.
The uplink is the hard half, because the first mile is the part nobody controls. Loss, jitter and route flaps on a residential connection are what destroy a stream, and they worsen with distance.
What they chose
Twitch's 2022 post on ingesting live video at global scale describes nearly a hundred points of presence, each connected to a private backbone, with streams received at a PoP then sent on to origin data centres for processing and distribution. The 2023 State of Engineering post adds the shape: the edges connect to local ISPs so streamers reach the network quickly, and after a stream connects the edge chooses one of the larger data centres - the origins - which hold hundreds to thousands of servers dedicated to transcoding.
So the PoP terminates the session and the origin does the compute.
Why it fits their constraints
Transcoding cost is per concurrent stream, not per viewer, and it is lumpy. One stream occupies a fixed slice of encoder capacity for as long as it runs. If you put encoders at a hundred PoPs, you must provision each site for its own local peak, and that peak is set by whichever creators happen to be nearby at the time. The demand is small per site, highly variable, and cannot be pooled across sites.
Consolidating into a few origins pools that demand globally, so the encoder fleet is sized for worldwide concurrent streams rather than the sum of a hundred local peaks. For a workload with lumpy per-unit cost that difference is not a few percent; it is the difference between a viable fleet and a hundred half-idle ones.
The latency argument survives because the hop that matters is the uncontrolled one. Getting the creator onto a managed network within a few milliseconds removes the public-internet path where loss lives. The PoP-to-origin hop is longer in distance but runs on a private backbone with predictable round-trip time and loss, so adding it costs milliseconds of known latency to remove tens of milliseconds of unknown jitter.
What it cost them
A control plane that must choose an origin per stream and re-choose it when one is unhealthy. A larger failure domain per origin than per PoP. A private backbone, which is a capital commitment rather than a configuration. And a longer physical path for every stream, acceptable only because its variance is low.
When copying this would be the wrong answer
If your per-unit compute is small and per-request rather than per-session, the pooling argument disappears. Resizing an image or evaluating a rules engine costs milliseconds of CPU and pools fine anywhere, so the thing that made consolidation correct for transcoding does not apply and edge execution wins on latency.
If you do not own a private backbone, the second hop is the public internet. You have then added a hop and bought none of the predictability that justified it. For most companies the honest version of this topology is: terminate the connection at a managed edge your CDN vendor already operates, and do the compute in one or two regions.
And if you have hundreds of concurrent streams rather than millions, transcode in one region. Two-tier ingest answers the number and spread of distinct creator uplinks, not viewer count. A plain round trip from the creator to a regional service is the right answer until measured first-mile loss, not theoretical distance, is costing you streams.