Multi-CDN is not one architecture but a family, and picking the wrong member costs more than picking none: an estate built for failover cannot suddenly steer on performance, and a client-switching design demands player work a website doesn’t have. Four patterns cover almost every real deployment, rising in both power and operational appetite. Choose by what must survive and what the team can run — not by what demos well.
The shared foundations every pattern needs
Whatever pattern you choose, four foundations are common — and they are most of the build. Every hostname needs valid certificates and complete configuration on every CDN at all times, per the estate-wide cert and DNS discipline. Configuration parity — caching rules, security controls, token schemes — must hold across platforms, or switching platforms silently switches behaviour (the sync guide and the security parity programme cover the how). The origin must accept and distinguish every CDN. And you need independent measurement — external synthetics plus RUM — because every pattern’s routing decisions are only as good as the data feeding them. Teams that build foundations first find the pattern layer thin; teams that start with the routing toy discover the foundations mid-incident.
Pattern 1: active-passive failover
One CDN serves everything; the second holds warm configuration and receives traffic only when the first fails, switched by DNS failover records or a manual runbook step. This is the cheapest pattern in every dimension: no cache dilution in normal operation, minimal steering machinery, and the second commit can be small or usage-based. Its weaknesses are symmetrical: the passive platform’s cache is stone cold at activation (expect an origin surge and degraded hit ratio exactly when things are already bad — pre-warming critical objects on failover is worth automating), and an unused platform rots — configs drift, certs lapse — unless you exercise it on a schedule, which is why the working rule is a monthly canary: a small hostname or traffic slice lives permanently on the secondary as proof of life. Right for: estates whose score in the scorecard was driven by availability alone.
Pattern 2: DNS-weighted active-active
Both CDNs serve constantly, split by weighted DNS — 70/30, 50/50, whatever the commits and confidence suggest — with health checks pulling a failed platform’s weight to zero. Both caches stay warm, failover is a weight change rather than an activation, rot is impossible, and the split ratio becomes a commercial instrument at renewal time. The price: cache heat divides across platforms (hit ratio drops a few points; the shared-origin design in zero-egress origins softens the origin-side cost), and every user-facing behaviour now must be identical on both platforms, since users land on either arbitrarily. The DNS mechanics — TTLs, health-check design, resolver caveats — are a build of their own, walked step-by-step in DNS-based steering. Right for: most estates that genuinely need multi-CDN; this is the workhorse pattern.
Pattern 3: performance-steered routing
Active-active, but the split is decided per geography, per ASN, even per request-time measurement rather than by fixed weights: managed DNS platforms with telemetry feeds route each resolver to whichever CDN currently serves its network best. This is where multi-CDN stops being insurance and starts being a performance feature — each network gets its best provider, and the estate’s aggregate latency beats either platform alone. The demands rise to match: you need trustworthy per-network measurement (RUM-fed steering is the honest version — the full loop is its own guide), steering logic with damping so decisions don’t flap, and enough traffic per network for the statistics to mean anything. The product landscape for this tier — managed DNS with filter chains, commercial steering platforms, orchestrators — is mapped in our orchestrator comparison. Right for: global audiences, QoE-sensitive products, teams already strong on measurement.
Pattern 4: client-side switching, and choosing
The most powerful pattern moves the decision into the client: the application or player knows every CDN’s hostname and chooses per session or even per object — retrying a failed fetch on the other platform in milliseconds, no DNS propagation involved. For video this is mature practice (per-segment switching and standardized content steering — the setup is the video guide); for web estates it means service-worker or application logic and is rarer. It survives what DNS patterns cannot — resolver misbehaviour, stale TTLs, mid-session platform failure — at the cost of owning routing logic in shipped code, with shipped-code release cycles; the trade against DNS-layer control is dissected in our steering-vs-switching piece. Choosing across the four: availability-only need, low appetite → pattern 1; general case → pattern 2, graduating to 3 as measurement matures; video at scale or session-survival requirements → pattern 4 for the media path, usually atop pattern 2 for everything else. Write the choice down with its trigger for graduation — architecture reviews go better with the reasoning on paper.