How to choose a multi CDN solution

How to implement a multi-CDN strategy: everything you need to know

As online video consumption (literally) reaches new peaks, new challenges are arising for industry newbies and veterans alike. This summer, the 2018 World Cup set an all-time streaming record – tripling its own 2014 record – with over 22 Tbps measured by Akamai at peak, but the event wasn’t smooth sailing for everyone. In a highly competitive market, and in an age where streaming failures make headlines, redundancy and quality of experience have never been more crucial for content publishers.

To ensure a consistent high-quality video experience, more and more broadcasters are turning to multi-CDN strategies, deploying several CDNs in their video delivery workflow.

Why opt for a multi-CDN strategy?

There are several reasons content owners choose to implement a multi-CDN solution:

Improve CDN Performance – Using multiple CDNs can ensure the best coverage by opting for the CDN that performs best in a given country, region or ISP. In addition to using a particular CDN in the region it is strongest, a multi-CDN strategy can also help alleviate network congestion and ensure viewers receive their video from the best source available. These types of solutions vary from static geography-based rules that choose the CDN based on viewer location, to tools that make data-driven CDN choices based on real-time aggregated quality data, or even local viewer stats. Routing traffic to the most efficient content source, these systems improve availability, latency, start-up times, and throughput on a large scale.

Redundancy – When the press is more than happy to cover service outages, diversity has never been so important, especially for highly-anticipated live events that attract multitudes of viewers. Using several CDNs strengthens reliability and provides an efficient failover mechanism; if one CDN fails, another one can take over to ensure continuity.

Agility – Having a multi-CDN system in place helps broadcasters avoid vendor lock-in. Changing, adding or removing a CDN is easy and can be done with a click of a button from one day to the next.

Efficient CDN cost management – As CDNs become increasingly commoditized, committing to one CDN no longer offers the financial benefit it once did for content owners. With a multi-CDN solution, however, broadcasters can optimize contract commit usage with each vendor, avoid expensive surcharges and decrease overall spend. Moreover, the option of sending traffic to different CDNs offers more leverage in pricing negotiations, as content delivery networks must compete on a performance basis for publishers’ business.

How to implement a multi-CDN strategy

Whatever your reasons are for adopting a multi-CDN strategy, following the steps below will help you avoid potential pitfalls and get the most out of your video delivery workflow:

Step 1: make your video workflow multi-CDN ready

Remove any dependencies that tie you to a specific CDN. First, make sure to have a unified origin that can be used by different CDNs, which are configured as edges only. Then, whether it’s DRMs, special video players or transcoders, your entire workflow needs to be compatible with any CDN. Later you might also want to make sure your multi-CDN switching tool can work with different tokens.

Step 2: engage with multiple CDN vendors

Get in contact with several CDN providers and have them offer competing proposals, avoiding commits as much as possible.

Step 3: plan your switching strategy

The policy that governs CDN selection and switching is the most important part of a successful multi-CDN strategy. Establishing the right rules for your use case involves looking holistically at your different goals: business criteria, cost considerations and quality expectations. Your multi-CDN strategy can be based on different types of decision criteria:

Static business rules statically determine what CDN is used for specific stream types, geographies, ISPs or devices. These rules may be applied at all times, or vary depending on the time of day.

Commit-based rules switch CDNs according to the bandwidth already consumed during the relevant time period with each CDN, taking into consideration volumes remaining to reach the commit and overage rates. Applying these criteria usually requires APIs into CDN traffic data, which not all CDNs support, meaning that in many cases these switches need to be handled manually. When an API is not available, broadcasters may opt to set up approximate usage thresholds for each CDN in advance.

Global QoS-based rules choose the best performing CDN by querying a database of QoS statistics. These quality statistics can come from real-time CDN metrics such as latency, RTT, and errors, or player metrics such as buffering, bitrate and startup time. The dataset meanwhile can come from either the global data of an analytics provider, or from a custom set of QOS data from your own audience.

Global information is usually free and is a good solution for broadcasters with relatively little traffic and tight budgets. However, it can include aggregation biases that are not relevant to your specific traffic and can therefore prove highly inaccurate. Broadcasters with enough viewers and the right budget should opt for stats from on their own audience.

Per-device QoS-based decisions – As mentioned above, Global QoS-based rules make switching decisions according to an average of how a CDN handles millions of different videos under different (and changing) conditions, geographies, ISPs, infrastructure, and times. This average doesn’t necessarily provide a meaningful insight when it comes to the individual viewer’s experience. On the other hand, multi-CDN switchers that reside on the client-side – within the player – are able to make independent switching decisions according to actual QoS feedback from the device, allowing unique delivery optimization for each and every user.

Once you identify your decision criteria, you’ll need to prioritize them. Should switches be first based on price? Quality of service? Geography? Should different regions apply different policies? Should different devices or stream types use different CDNs? The best way to articulate a multi-CDN strategy is by using a decision tree as in this example:

multi cdn strategy

Step 4: choose your multi-CDN switching tool

Although there are quite a few solutions on the market, some broadcasters choose to create their own CDN switcher. This in-house approach allows for manual, or in better cases,  automated switching, and can do the trick when applying a simple multi-CDN policy. However, most content publishers do not have the resources to create and maintain a sophisticated solution that can handle complex rules balancing multiple dynamic criteria. Homemade switches are most often used to apply a cost-based policy, to switch between CDN vendors according to commit, or to implement basic geography-based rules.

Whether you opt for an in-house or a third-party solution, it’s important to understand how various types of multi-CDN switchers work, and how they differ from one another:

Multi-CDN aggregators combine and centralize multiple CDNs by different vendors, while managing all aspects of the decision-making through one dashboard. This method can work for publishers who don’t have the resources to dedicate to the administration of a dynamic CDN policy, who don’t require a lot of customization and who are willing to give up control on how switching decisions are made.

DNS multi-CDN solutions switch CDNs by changing the DNS entry for the stream URL. These solutions are very simple to implement, as the video source URL remains constant. In this case, the switch delay depends on the DNS entry TTL (Time to Live), meaning that this is probably not the best choice for QoE. It is also not ideal from a redundancy perspective: DNS-based switching simply replaces one single-point-of-failure – the CDN – with another – the DNS resolver. If this service fails, everything else goes down with it.

On-the-fly manifest rewrite with a proxy – This method switches CDNs by rewriting the manifest in real-time. The manifest is edited on-the-go and sent to the viewer’s player whenever there is a switch, changing the video segments URLs within the manifest according to the current best CDN. This solution provides better user experience as it enables midstream switching that does not require a hard refresh to resume video play. It also eliminates the risk of a cascade effect over your video workflow that can be caused by thousands of simultaneous session resets. However, similarly to DNS-based solutions, here too we replace one single point of failure with another. In addition, rewriting the manifest can be risky as any error can be detrimental to your stream. And although the switch is done instream, it is not completely seamless; it can take more than a few seconds for the server to learn (from the client) about a CDN unavailability.

Server-side API CDN switchers reside server-side in your back office. Each time your webpage loads, your backendsends the most appropriate CDN according to static internal geography, business or cost rules, or dynamic third-party QoS data. These solutions are easier to control since any changes can be done directly on your server; however, they can add some delay in page load time, and take less accurate QoS-based switching decisions, as they act based on aggregated data and not individual QoS feedback from the actual device.

Client-side CDN switchers sit on the client-side within the video player. They take QoS-based decisions based on the real-time conditions perceived by the individual user device. They also enable midstream switching on a segment by segment basis, which means a seamless viewing experience for the viewer and no need for a hard refresh. This method is the most accurate QoS-wise; however, it is more complex to implement when built in-house, as the decision-making algorithm requires detailed planning, experimenting and tweaking. Among other things, you’ll need to decide, for example, what bitrate is tolerable for the specific device and player size, how many CDN errors should trigger a reroute, etc.

Choosing the right multi-CDN switching tool is the final and most important step, as it relies greatly on content owners’ business needs and priorities. However, even when those are well defined, the challenge still remains; as you can see, it is not always simple to find a solution that ticks all the boxes.

Streamroot CDN Orchestrator: the best of all worlds

Last September at IBC Streamroot presented Orcherstrator, a client-side midstream CDN switcher. This unique tool applies broadcasters’ business, cost/commit and geography-based policies in tandem with individual device-based QoS load-balancing.

Benefiting from our expertise in video segment multisourcing, as well a unique position and compatibility with the most popular video players on the market, we were able to create the first multi-CDN switcher that is both client-side and midstream. Orchestrator is able to dynamically select the best video source according to specific user device metrics, multisourcing video segments from the best CDN available for the individual viewer at any given time.

Optimizing delivery to each individual viewer, Orchestrator seamlessly switches video sources midstream, eliminating the need for viewers to refresh in case of CDN failure, and preventing the cascade effect on broadcasters’ video workflow that can be caused by a massive wave of session resets. The Orchestrator easy-to-integrate module can also be integrated with best-in-class third-party global databases to determine the initial, start of the session CDN.

You can learn more about Orchestrator in our multi-CDN dedicated webinar and in our Compass product demo:

If you’d like to be one of the first to optimize viewer experience with Orchestrator, drop us a line at, or simply fill in the form below.

Scroll to Top