One CDN is a single point of failure

Every few quarters a major network has a morning. Dashboards go red. Status pages lag the internet. Social media discovers the word “PoP.” Then the post-mortems arrive, and someone writes that this is another wake-up call for resilience planning.

It is. It is also a calendar event. Single-vendor concentration is a risk buyers now price in, whether the RFP says so or not.

Multi-CDN is the unglamorous response: more than one network in front of the same origin, with something intelligent enough to steer, fail over, and not make the cure worse than the outage.

What multi-CDN is not

It is not two logos on a slide. It is not “Cloudflare for the US, Fastly for Europe” as a personality. It is not a second contract you never fail over to, because the TLS certificate on the backup expired in March.

If you cannot answer what happens in the first ninety seconds, you do not have multi-CDN. You have a spare invoice.

The actual moving parts

A working setup is four layers that people keep collapsing into one:

1. DNS or traffic steering — the decision about which network should answer. This is where NS1, and the Cedexis/OpenMix lineage inside it, still earn their keep: performance, availability, and sometimes cost as inputs, not a static weighted record you forgot.
2. Equivalent configuration — cache keys, headers, compression, TLS, redirects. Two CDNs with different cache keys are two different websites that happen to share an origin.
3. Origin discipline — shielding, request coalescing, and the grim fact that failover can stampede a healthy origin if you warm nothing and fail everything.
4. A drill — not a runbook in a wiki. A drill. Quarterly. With the people who will be awake.

Skip any one of these and you will discover it during an incident, which is the most expensive classroom on earth.

When a second network is worth it

You probably do not need multi-CDN if:

• A four-hour vendor incident is embarrassing but not existential.
• Your traffic would not notice a regional blip.
• Nobody on the team can explain your current cache key.

You probably do if:

• A minute of downtime is a commercial event (flash sales, live media, checkout).
• Your current CDN is also your WAF, your DNS, and your bot product — one outage, four symptoms.
• You already pay for a “backup” that has never seen production traffic.

The middle of that list is the quiet one. Platforms keep absorbing adjacent products. That is convenient until the convenience is correlated.

Failover that does not melt the origin

The reflex, when a cache goes cold, is to push: reactivate everything, warm aggressively, declare victory. That can turn a delivery problem into an origin problem. The slower move is usually the adult one — progressive steering, sitemaps and actually-crawled URLs first, learning mode before bravado.

Boring in appearance. Surgical in reality. It requires someone who can see performance, security, and crawl as one system, not three tickets.

Buying a second CDN is the easy part. Steering, cache keys, TLS, and failover drills are the work. Teams that do not want another control plane to staff often treat this as a managed practice; Optimi describes it as orchestration rather than another dashboard.

A note on DNS

If your failover lives in an A record with a 300-second TTL and a human with a laptop, you have a prayer, not an architecture. Traffic steering at the DNS layer — health-checked, measured, reversible — is the difference between “we have two CDNs” and “users actually moved.”

NS1’s reason to exist, for many serious stacks, is exactly this: the decision plane is not the data plane. Keep them from sharing a fate when you can.

For how vendors differ before you dual-home them, start with There is no best CDN. For why the same steering question shows up in Search Console, see Googlebot lives at the edge.