Multi-CDN is the most recommended architecture nobody scopes honestly: the availability argument is real, the costs are real too, and both arrive permanently. Before any vendor call, run the scorecard — five questions with numbers attached — and let the score make the decision. A defensible “no” or “not yet” is a perfectly good outcome; the expensive outcome is a second CDN adopted by vibe and abandoned by Q3.
What multi-CDN actually buys
Four things, in descending order of how often they justify the project. Availability: no single provider’s bad day takes you down — the argument everyone cites, decisive only if your downtime cost is genuinely high and your own origin and DNS aren’t bigger single points of failure. Regional performance: no CDN is best everywhere, so steering each geography or ASN to its strongest platform buys real latency and QoE where your audience is diverse. Capacity: for launches and marquee live events, two providers’ headroom beats one’s. And leverage: a working second platform changes every renewal conversation — a benefit that is commercial, measurable, and only real if traffic can actually move. Rank these for your business before scoring; a media company and a B2B SaaS weight them very differently.
What it actually costs
The costs are structural, not setup-shaped. Engineering: every delivery change now lands on two platforms with different rule engines — config sync, test suites, and the parity discipline of keeping configurations in sync become standing work. Security: your protection equals your weakest edge, so the whole parity programme comes with the territory. Cache efficiency: traffic split two ways halves each platform’s object heat; hit ratios drop and origin load rises, a mechanic explored in our cache-fragmentation piece. Commercials: two smaller commits price worse per GB than one big one, partially offsetting the leverage gain. And operations: monitoring, logging and incident process all double in surface. None of these is fatal; all of them are forever, and the scorecard exists to weigh them against section one honestly.
The five-question scorecard
Score each 0–2. One: what does an hour of full outage cost, in money and standing? (0: an inconvenience; 2: material revenue or contractual damage.) Two: how geographically diverse is the audience? (0: one region; 2: global with meaningful traffic in regions where different providers demonstrably lead.) Three: do traffic events exceed what one provider comfortably commits to you — launches, live events, seasonal walls? (0: flat; 2: regularly.) Four: can the team run it — is delivery config in code, tested, owned? (0: dashboard-driven by one person; 2: pipeline-driven with review.) Five: is your workload portable — standard caching and rules, versus deep dependence on one vendor’s compute, image, or security stack? (0: deeply bound; 2: portable tomorrow.) Eight-plus: build it. Five to seven: not yet — do the readiness work in section five. Under five: a single well-run CDN with a rehearsed incident plan is the better spend, and our wider analysis piece reaches the same fork from the market side.
Scoring honestly: the common self-deceptions
Three scoring errors recur. Inflating question one after reading about someone else’s outage: price your downtime from your revenue curve, not from headlines — and remember the alternative to multi-CDN isn’t nothing, it’s the single-CDN incident playbook in the outage guide, which captures much of the availability value at a tenth of the cost. Ignoring question four: an untested second CDN is not redundancy, it is a decoration that fails on activation day — readiness is the gating question, and teams score themselves generously on it. And skipping question five’s honesty: if your WAF, edge functions and image pipeline are all one vendor’s proprietary stack, you don’t have a multi-CDN decision yet, you have a portability project — see edge compute without lock-in for the untangling.
The not-yet path and the trigger list
“Not yet” is a plan, not a deferral. Do the work that raises the score and pays off regardless: move delivery config into code; build the external monitoring and the outage playbook; make the workload portable by preferring standard mechanisms over vendor-exclusive ones; and negotiate contracts that don’t punish a future second provider (no exclusivity, commits sized to a splittable share). Then write the trigger list — the events that reopen the decision automatically: an outage exceeding your stated tolerance, expansion into a region your provider serves poorly, a launch bigger than the provider will commit to, or a renewal quote that needs leverage. Revisit the scorecard when a trigger fires, not annually by habit. If the score says build, the next stop is choosing the architecture pattern — where the how turns out to matter as much as the whether.