A live-sport streaming platform of the kind Hotstar operates has budget to make exactly one more layer redundant before a tournament. Today it has: a single cloud region with three availability zones, one database primary with a standby in the same region, one CDN provider, and one identity provider for sign-in. Which should it buy?

The deciding property

Which single failure has no workaround and affects every user at once. Redundancy is bought against correlated total loss, not against the failure you have seen most recently.

Work the four candidates against that test:

• CDN: a single provider's control-plane or configuration failure affects all delivery simultaneously, there is no degraded mode (video cannot come from origin at this scale), and provider-wide incidents are documented and recurrent in the industry. No workaround, total impact.
• Second region: real protection against a region loss, which is rarer, and the three zones already cover the most likely infrastructure failures. It is also the most expensive option by a wide margin.
• Second standby in another zone: the standby already exists; a second one reduces the chance of a failover having no target, which is a small marginal gain.
• Second identity provider: sign-in failure is severe and has a partial workaround — existing sessions keep working, and anonymous viewing can be permitted for a live event.

Why the CDN

For live video, delivery is the product. Everything else has a degraded mode: a slow database means a slower home page, a sign-in outage still serves already-authenticated viewers, a lost zone costs capacity. A CDN outage during a final means nobody can watch, for the duration, with nothing the platform can do from inside its own estate.

The second reason is that it is the only option on the list where the failure is outside your control and the mitigation must be in place before the event. A region failover can be practised and executed; a provider's global incident cannot be fixed by you at all.

What it costs: multi-CDN means two configurations to keep consistent, two cache populations to warm, a traffic-steering layer that must itself not fail, and commercial minimums on both contracts — typically a double-digit percentage uplift on delivery spend. Cache hit ratio also falls when traffic is split, because each provider's edges see less of the catalogue, which raises origin egress.

Why the other options fail

Second region. Protects against the rarer failure at the highest cost, and for a live event the state that matters is largely a delivery problem rather than a regional compute problem. It is also the option most likely to be bought and never exercised, which makes it a plan rather than a capability.

Second standby in another zone. The marginal gain over one standby is small, and the common failure in practice is not "the standby was missing" but "failover was never tested" or "the standby had the same corrupt data". Those are rehearsal problems, not redundancy problems, and money does not fix them.

Second identity provider. Genuinely valuable and second on this list. It loses because the partial workaround exists: for a live event, permitting already-authenticated sessions to continue and relaxing sign-in requirements keeps most of the audience watching. A mitigation that exists inside your own control beats one that must be bought.

When this is the wrong purchase, and what would flip it

If the platform has never rehearsed the failover it already has, buy the rehearsal instead. An untested second path is worth less than a tested single one, and the common cause of a long outage is not missing redundancy but a failover nobody has executed.