Streaming an Olympics: the hardest scaling problem nobody discusses

The Winter Olympics start today, which makes this a good moment to talk about a category of engineering problem that gets almost no coverage despite being one of the hardest in production computing.

Live streaming a global sporting event has a combination of constraints that almost nothing else has.

why it is hard#

The demand is synchronized. Web traffic is normally a smooth curve. A live event is a step function — millions of people join within the same sixty seconds, at a moment you know in advance and cannot move.

You cannot shed load. The standard answer to overload is to degrade: serve cached content, drop non-essential features, queue people. None of those work when the product is a live video feed. A queue means the user misses the thing.

Latency is a correctness constraint. If your stream is forty seconds behind broadcast, viewers learn the result from their phone before they see it. That is a product failure with no technical symptom — every metric is green and the experience is ruined.

Peak is unpredictable within a predictable window. You know the event starts at 8 p.m. You do not know that a particular race will be close and that traffic will spike 3× in the final ninety seconds.

You cannot test at scale. There is no staging environment with fifty million concurrent viewers. Load tests approximate. The real event is the test.

the architecture, roughly#

Ingest — camera feeds encoded at the venue, sent over dedicated circuits, with redundant paths because a fiber cut during a final is a career event.

Transcode — one source becomes a ladder of bitrates and resolutions, times several codecs, times audio tracks and languages. That is a large multiplication and it happens in real time with no room to fall behind.

Packaging — segmented into chunks, typically 2 to 6 seconds, in HLS and DASH. Low-latency variants use much smaller chunks or chunked transfer encoding to cut the delay, at the cost of more requests and worse cache behavior.

Distribution — multiple CDNs, always. Not for capacity alone but because CDNs have bad days, and a client-side switching layer that measures performance and moves traffic is the difference between a degraded minute and an outage.

The client — adaptive bitrate logic that decides which quality to request based on measured bandwidth and buffer level. This is where a surprising amount of the perceived quality difference between services actually lives.

the parts that are counterintuitive#

Cache hit ratio is everything, and low-latency streaming ruins it. A 6-second segment requested by a million people is one origin fetch and a million edge hits. Cut to 1-second segments for lower latency and you have six times the requests, each with a shorter window to accumulate hits. Latency and efficiency are in direct tension and every service picks a point on that curve.

The last mile is not yours and dominates the experience. Home wifi, congested cell towers, and oversubscribed ISP links cause most of the buffering users blame on you. The only lever you have is graceful adaptation — dropping quality smoothly rather than stalling.

Advertising insertion is a distributed systems problem. Server-side ad insertion means personalizing a stream per viewer while keeping segments cacheable, which is a genuinely hard constraint and is where a lot of live-stream failures actually originate.

The failure mode that matters is the thundering herd on recovery. When something breaks and comes back, every client reconnects at once. Without jitter on the retry, recovery causes a second outage. This is the single most common way these events go badly.

the lesson that generalizes#

Almost every hard part here is about synchronized demand you cannot smooth and cannot refuse.

Most systems get to spread load over time, shed it, or queue it. When you cannot do any of those, you are left with provisioning for peak, redundancy at every layer, and graceful degradation that preserves the core experience.

That is expensive and it is the only thing that works. Which is worth remembering when someone proposes autoscaling as the answer to a spike that arrives faster than an instance can boot.

Some problems you solve with capacity you already own.