Multi-CDN
Multi-CDN is a delivery setup that serves the same video through two or more content delivery networks and decides, for each viewer or request, which one to use. The decision can rest on measured performance, region, cost or a live outage. Each CDN has different server locations and different connections to internet providers, so the fastest network in one country is often not the fastest in the next. If one CDN slows down or fails in a region, new requests move to another and playback keeps going.
How does multi-CDN routing work?
There are three common places to make the choice. DNS steering answers the viewer's lookup with the hostname or address of the chosen CDN. It is simple, but DNS answers are cached, so a switch can take minutes to reach everyone. Session-level steering picks a CDN when playback starts, usually by rewriting the manifest or redirecting the first request, which gives a fresh decision for every view.
The third option is client-side switching. The player itself holds a list of CDN hosts and moves to another one mid-stream if segment requests time out or slow down. That reacts fastest, because it happens inside a single view.
Whichever method is used, the decision needs data. Synthetic probes test CDNs from data centers. Real user measurement, collected from players during actual views, shows what each CDN delivers on each internet provider, and that is the signal that matches what viewers see.
Why use multi-CDN?
The first reason is resilience. Every CDN has bad hours: a routing fault, a congested exchange, an overloaded region. With one CDN, viewers in that region stall until it recovers. With several, traffic moves away from the problem.
The second reason is coverage. CDNs differ by country and by internet provider. One may peer directly with a country's main mobile carriers while another reaches the same users through a longer path. Routing per region lets each viewer use the network that is fast where they are.
The third is capacity at peaks. Live sport is the clearest case: the whole audience arrives in the same minute at kickoff and asks for the same new segments. Spreading that load across providers keeps any single one from saturating. The same applies to scheduled premieres and to seasonal evening peaks that repeat for weeks.
Multi-CDN vs. a single CDN
A single CDN is simpler. There is one cache to warm, one set of logs, one token format for signed URLs and one configuration to maintain. For a small audience in one region, it can work well.
Multi-CDN adds engineering work. The cache is split across providers, so each one has a lower hit ratio and the origin sees more requests. That usually calls for an origin shield, a cache layer in front of the origin that absorbs repeated misses. Signed URL tokens must validate the same way on every CDN, or switching breaks playback for protected content. Logs arrive in different formats and need normalizing before anyone can compare them. Routing rules need tuning and regular review.
The trade is resilience and regional performance in return for that complexity. The work is the same whether you build it yourself or it comes built into a platform; the question is who carries it.
What does a multi-CDN setup need to work well?
Routing between CDNs is only as good as the plumbing around it. Multi-CDN setups more often break on the parts around the routing decision than on the decision itself: a token that one CDN rejects, a cache rule that differs, or an origin that buckles when every provider misses at once. A working setup needs these parts in place.
- The same manifests, segments and cache rules published to every CDN.
- An origin shield, so cache misses from several providers do not overload the origin.
- Access tokens that validate identically on every CDN.
- Real user data per CDN, broken down by country, region and ASN.
- Health checks and failover rules that move traffic automatically, not after a ticket.
- A player that retries a failed segment on another host instead of stalling.
How does FastPix handle multi-CDN?
Multi-CDN is part of FastPix delivery, not an add-on. Every on-demand video and live stream is served across a multi-CDN network of 300+ points of presence. Edge routing is chosen per viewer automatically, and on-demand delivery has per-region failover, so if one CDN degrades in a region, traffic moves to another. There are no CDN contracts for your team to hold and no routing layer to run. Live concurrency scales with your plan, so there is nothing to provision before an event.
The same delivery covers everything the player loads, video, posters, storyboards and thumbnail images, and all of it can be served from your own custom domain. A custom domain keeps one hostname in front of the mesh, so the CDN choice behind it does not show up in your page or app.
Video Data supplies the viewer-side measurement that multi-CDN depends on. It records which CDN served each view, along with startup time, buffer ratio, request latency, throughput and errors from the player itself. QoE can be broken down by country, region, CDN and ASN, so a slowdown on one internet provider shows up in the breakdown rather than in support tickets. Threshold alerts can be routed to PagerDuty, Slack or Opsgenie.
Routing between CDNs is not a separate line item. Viewing is billed per minute watched on demand and per viewer-minute on live, with transfer between CDNs and regions included. Storage bills per rendition-minute and Standard encoding is free up to 4K. The free plan includes 100,000 streaming minutes and 30 live minutes a month, with no card needed.
