Concepts
Multi-CDN Routing
Route playback traffic across multiple CDN providers or delivery paths so a live event can survive regional failures, overload, and uneven network performance.
After this, you will understand
How Multi-CDN Routing helps you see where this idea appears in production systems, what problem forces it, and how to reason about the tradeoffs.
Treat the idea as a definition to memorize.
Real systems force the idea to handle CDN Health, Traffic Steering, and Origin Shield.
Use the concept to decide what the system guarantees, what it risks, and what it costs to operate.
Think before readingWhere would Multi-CDN Routing appear in a real production system, and what failure or bottleneck would it help you reason about?
Reading in progress
This page is saved in your local study history so you can continue later.
Concepts Covered
- CDN health
- Traffic steering
- Regional failover
- Session stickiness
- Origin shielding
- Route flapping
- Cost and performance tradeoffs
Definition
Multi-CDN routing sends playback traffic across more than one CDN provider or delivery path.
Instead of assuming one CDN will always serve every viewer well, the platform can choose different paths by region, ISP, event, device, health, performance, and cost.
For live events, multi-CDN routing is especially useful because the audience is concentrated. If one CDN has a regional issue during the first round of a fight or the first minutes of a sports final, the platform needs a way to move traffic without stopping the event.
The Pain That Forces This Concept
A single CDN strategy is simple:
viewer -> CDN A -> origin
This can be enough for many products. But global live events expose uncomfortable failure modes:
- CDN A is healthy globally but failing for one ISP
- one region sees elevated segment latency
- cache misses overload a delivery path
- a provider has an incident during the event
- one CDN handles manifests well but media segments poorly in a market
- draining traffic too quickly overloads the backup path
The platform does not control every network between viewer and edge. Multi-CDN routing gives the platform more delivery choices.
Mental Model
Multi-CDN routing is traffic control for media delivery.
same live event
-> viewers in region A use CDN 1
-> viewers in region B use CDN 2
-> struggling viewers get fallback paths
The goal is not to find a universally best CDN. The goal is to avoid having one delivery provider become the only failure boundary.
How It Works
Routing can happen in several places:
- DNS response
- playback API response
- manifest URL selection
- player fallback list
- edge redirect
- server-side traffic steering service
A common playback flow:
1. Player asks Playback API for live event startup data.
2. Playback API checks entitlement and region.
3. Multi-CDN router evaluates health and policy.
4. API returns manifest URL and fallback CDN options.
5. Player fetches segments from the selected CDN.
6. Player telemetry reports startup, errors, bitrate, and rebuffering.
7. Router updates future decisions from aggregated health signals.
The router should avoid overreacting to noisy data. If it flips traffic every few seconds, viewers may bounce between paths, cache efficiency can drop, and incidents can spread.
Tradeoffs
| Choice | Benefit | Cost |
|---|---|---|
| Single CDN | Simple operations | One large outage domain |
| Multi-CDN | Better resilience and regional performance | More integration and routing complexity |
| Aggressive failover | Fast reaction to incidents | Risk of route flapping |
| Conservative failover | Stable routing | Slower recovery |
| Per-session stickiness | More stable playback | Slower migration away from bad paths |
| Per-segment decisions | Fine-grained control | Higher complexity and cache churn |
| Cost-aware routing | Lower delivery cost | May choose weaker performance paths |
The hardest part is not adding a second CDN. The hardest part is deciding when and how to move traffic without making the incident worse.
Operational Reality
Operators watch:
- startup success by CDN
- segment download latency by CDN, region, and ISP
- CDN 4xx and 5xx rates
- manifest fetch errors
- rebuffer rate by route
- cache hit ratio
- origin shield request rate
- traffic distribution
- failover actions
- route flapping frequency
Failure modes:
- bad health signals move traffic away from a healthy CDN
- failover sends too much load to the backup CDN
- players switch paths too often and lose cache locality
- signed URLs are valid for one CDN but not another
- regional rights rules are applied inconsistently across delivery paths
- origin shielding is bypassed during reroute
Related Topics
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
Used In Systems
System studies where this idea appears in context.
Related Concepts
Core ideas that connect to this topic.
Related Patterns
Reusable architecture moves built from these ideas.