Most content providers rely on multiple CDNs to protect against outages and performance degradation, but traditional multi-CDN strategies remain largely manual and reactive. A more advanced approach is emerging: CDN federation. By intelligently distributing traffic across networks in real time, providers can improve resilience, performance, and operational efficiency simultaneously.
The idea of relying on a single content delivery network (CDN) probably gives many content providers heartburn. Whether that provider is delivering a game download or streaming video or an e-commerce website, a complete delivery outage can bring a digital business to a standstill…and have far reaching implications for the business. Even worse, consistent, unpredictable degradation to video quality or download speeds can impact subscriptions, in the case of OTT services, game downloads, or purchases. There is a direct correlation between a poor user experience and company profitability.
That's why almost every serious content provider uses more than one CDN. But multi-CDN is a fairly crude way of ensuring redundancy. That's because, unless you have a lot of engineering resources laying around, CDN switching is often done manually. Each CDN has some traffic, to keep the caches warm in the event of a switch over, but the switching often isn't automated. That's because operations engineers (or whoever is in charge of the CDN delivery architecture) need to examine what's happening, escalate to CDN or ISP partners, and figure out why even while moving the traffic from the degrading CDN to a better performing network.
What's really needed is a way to federate traffic between CDNs. That means an automated system, built on rules and leveraging the real-time data analysis of AI, that balances traffic across delivery networks. So rather than just switching, like in a multi-CDN system, traffic is spread across multiple CDNs in real-time.
Many content providers are familiar with multi-CDN. That's simply parsing up traffic by percentages and then assigning a percentage to each CDN in the mix. Multi-CDN is a pretty easy way to ensure delivery continuity (i.e., there is always a CDN capable of delivering traffic) but it's kind of a second-rate load balancing. Load balancing is a dynamic network operation. It moves traffic or requests across a pool of resources. The difference is that load balancing is a lower level network function compared to CDN switching carried out in multi-CDN architectures. Load balancing is not just about switching traffic from one route to another, it's about routing traffic to the best resource based upon pre-determined criteria and real-time analysis of the resource in question.
That's traffic federation in a nutshell — the application of network principles to moving traffic between different networks in a heterogeneous content delivery architecture. And it's not new. Cisco really explored this about 20 years ago. The problem back then was two fold. First, the technologies weren't really ready to apply load balancing principles to something like multi-CDN content delivery. Second, there were the business issues. When Cisco was exploring this, it became less about technology and more about how to share revenue between CDN and ISP.
Putting aside the business concerns and assuming that the technology exists today, it's not enough. There are a number of technical challenges that would keep any content operator from exploring, implementing, and benefiting from traffic federation:
Only even if these technical challenges are addressed (and they could with enough engineering resources to create a bespoke solution), there is still another to contend with.
The problem is that all of those challenges are magnified by scale. As the footprint of delivery capacity expands (through an increasing number of CDNs connected to the system), the complexity of the system expands as well. And this complexity is a factor of the amount of data, rules, and other operational impacts. In fact, it's easy to imagine that managing CDN traffic federation, when expanded beyond even just a couple of CDNs, could become almost all consuming.
When Cisco outlined the idea of traffic federation, they did so within the confines of a conference room filled with network operators, CDNs and ISPs. The idea was to get them to standardize interconnection (leveraging the work done in the IETF on CDNi). But with everybody approaching the solution differently, and mired in the thorniness of distributing revenue from the content provider, there was no way it was going to get implemented in a way that made everyone happy. So what if the answer isn't to build federation from within but to build it on the outside, as a service?
Traffic-Federation-as-a-Service would be similar, in concept, to how some services are approaching multi-CDN or content steering as a service. Here's how that service might look:
It's not hard to see how a system like this can start to take shape, offering content providers (especially those chained to a single CDN because of the complexity of managing multiple network interfaces) a way to take advantage of redundancy, reliability, and, most importantly, delivery continuity by using multiple CDNs without any of the operational overhead.
Perhaps one of the biggest advantages of using a TFaaS platform is how capacity can be expanded without spending any money. This works in two ways. First, from the platform perspective, the TFaaS operator can increase available capacity overnight simply by adding more network operators. Second, from the content provider's perspective, this means being able to access additional capacity for spikes or for improving delivery to hard-to-reach users (such as those connected to smaller ISPs in rural areas). Most individual CDNs today charge a premium for higher bitrate/throughput, when the amount of provisioned capacity is exceeded because of unforeseen circumstances (i.e., an exciting few minutes in a live sporting event). But what if, instead of pushing the additional traffic to a CDN that is already maxed out, that overage traffic can just be moved off to another provider. In today's world, that would mean the content provider would have to keep that secondary CDN warmed in the event of a spike. But if the spike never happens, it's just wasted money. In the TFaaS model, the spike is simply absorbed within the load balancing function of the system and spread to capacity that already exists.
The power of this system, over a traditional multi-CDN switcher, is that traffic is continually evaluated and the best route (i.e., the best CDN to use) selected based on that evaluation. That kind of automation benefits greatly from agentic AI. Imagine that instead of a business logic layer, there are a number of agents acting under the umbrella of a central orchestrator. Those agents are highly specialized in specific areas within the load balancing framework. So one agent is trained deeply in network performance analytics. Another is trained specifically to handle congestion and capacity evaluation. You get the picture. By stringing these agents together in their own federation, a single orchestrator, interfacing with each content provider's business rules for traffic delivery (i.e., don't ever use CDN X in region A), can shift traffic around in real-time, maximizing not only for cost but also for performance, availability, and even reliability (i.e., historical data on the CDN's performance over time).
Blockcast has been building a CDN solution that differentiates from traditional delivery. By using a DePIN approach, its CDN can be expanded without the capital investment that traditional CDNs need to expand their capacity footprint. But in doing so, in the vein of expanding the concept of CDN to mean more than a megalithic network operator controlling traffic delivery, Blockcast also looked at how they could point their CDN innovation to the complexity of multi-CDN architectures. CDN+ was born.
The Blockcast CDN+ offering is exactly the TFaaS system described previously. It's a single interface to multiple CDNs with everything about the load balancing of traffic across those CDNs abstracted from the content provider. All the content provider sees is how much traffic was delivered using traditional CDN logs and metrics. But behind the curtain, Blockcast's automated system, powered by agentic AI, is moving traffic between networks seamlessly. Content providers tell us, through a simple interface, a set of business rules and requirements, and CDN+ uses it, in conjunction with data received from the CDN networks and other probes, to route traffic in the most effective way in real-time.
Interested in offloading the complexity of your multi-CDN architecture? Want to explore using more than one CDN without having to take on the difficulty of CDN switching? Head on over to the CDN+ webpage and then drop us a line to try it out!
Multi-CDN typically distributes traffic across several CDNs using predefined percentages and manual failover processes. Traffic federation takes a more dynamic approach by continuously evaluating network performance, cost, capacity, and reliability, then automatically routing traffic to the most appropriate CDN in real time.
While multi-CDN provides redundancy, it often requires significant operational effort. Teams must monitor performance, analyze issues, coordinate with CDN providers, and manually shift traffic when problems occur. This reactive model can delay response times and increase operational complexity, especially during high-traffic events.
Organizations face several hurdles, including integrating with multiple CDN APIs, maintaining custom software, collecting and analyzing large volumes of performance data, and automating real-time traffic routing decisions. These challenges become increasingly difficult as additional CDNs are added to the delivery ecosystem.
Traffic-Federation-as-a-Service is a managed platform that abstracts the complexity of multi-CDN operations. Rather than building and maintaining custom federation systems internally, content providers use a single interface to define business rules while the platform automatically analyzes network conditions and routes traffic across participating CDNs.
Agentic AI can continuously monitor performance metrics, capacity availability, congestion levels, costs, and historical reliability data across multiple delivery networks. Specialized AI agents can evaluate these factors in real time and automatically shift traffic according to business objectives, helping maximize performance, availability, and cost efficiency without human intervention.
.png)