A stadium-scale live surge and a fifteen-year archive have opposite cache behaviour, opposite failure tolerance and opposite cost profiles. Most platforms are built for exactly one of them.
Put both workloads on one edge and the surge wins, every time, at the moment the archive can least afford to lose.
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. Cache it aggressively and hit ratio is near-perfect.
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, hot, constantly refreshed — evicts the archive's. When the match ends, every archive request is a miss against an origin that is also recovering.
| Live | On demand | |
|---|---|---|
| Working set | Tiny, moving | Large, static |
| Concurrency shape | A cliff, on a schedule | A smooth curve |
| Tolerance for a stall | None | Some |
| Right eviction policy | Aggressive | Conservative |
| Failure impact | Everyone at once | A few people |
Two edges. Same hardware budget, split rather than pooled, with their own cache policies and their own failure domains.
The gain is not only cache behaviour. It is that a live failure and an archive failure stop being the same incident — and on the night that matters, the thing you most want is for the blast radius to be smaller than the whole service.
Two machines held at a utilisation neither would justify alone. That is real, and it is the price of the failure domains. For a service that is purely on-demand it is not worth paying; for anyone carrying live events it is the cheapest insurance in the architecture.
More on how this shapes a broadcast deployment on the broadcasters page.
If the pattern in this write-up describes your setup, the next step is reading your actual numbers against it. Send twelve months of billing and your concurrency curve.