Live and on-demand want opposite things

Put both workloads on one edge and the surge wins, every time, at the moment the archive can least afford to lose.

The conflict, concretely

During a live event, tens of thousands of viewers request the same few segments within seconds of each other. The working set is tiny and it moves continuously, so caching it aggressively gives a near-perfect hit ratio.

An archive is the opposite: a large working set, sparsely and unpredictably accessed, where any given slice may be requested twice a week.

Share a machine and the live working set, small and hot and constantly refreshed, evicts the archive's. When the match ends, every archive request is a miss against an origin that is also recovering.

The structural answer

Two edges. The same hardware budget, split instead of pooled, with their own cache policies and their own failure domains.

The gain is not only cache behaviour. A live failure and an archive failure stop being the same incident. On the night that matters, you want the blast radius to be smaller than the whole service.

What this costs

Two machines held at a utilisation neither would justify alone. That is real, and it is the price of the failure domains. A purely on-demand service should not pay it, while anyone carrying live events is buying the cheapest insurance in the architecture.

More on what this means for a broadcast deployment on the broadcasters page.