A working active-active estate immediately poses its standing question: who serves what? The answer has three axes — ratio, geography, workload — and the good news is that they compose: a sensible estate might run 70/30 overall, assign two regions outright, and home video on one platform. The design work is making each assignment for a reason you can say out loud, and reviewing it on a calendar rather than never.
The three axes of a split
Ratio splits send a fixed percentage of everything to each platform — simple, uniform, the natural first configuration on weighted DNS. Geographic splits assign regions or countries to platforms — higher value, because provider strength genuinely varies by region, and higher maintenance, because the evidence needs refreshing. Workload splits assign traffic classes — video here, dynamic API there — and extract the most from each platform’s character at the cost of running visibly different setups. Most estates layer them in that order as confidence grows. One principle governs all three: every assignment must trace to either a commercial number (a commit to fill) or a measured number (a benchmark or RUM cut) — an assignment tracing to a hunch is a future incident’s root cause.
Ratios: commits, confidence, cache heat
Three inputs set the ratio. Commercial: commits want filling — if platform A’s contract assumes 400 TB a month and B’s 100, a 50/50 split wastes A’s pricing and may trigger B’s overage; size the ratio so both land comfortably in their bands, and let next renewal’s numbers reflect reality (the negotiation leverage is real, and it comes from demonstrated ability to move the ratio — our commercial-leverage piece runs those numbers). Confidence: a newer platform earns share gradually — start minority, grow as its incident record justifies. Cache heat: every percentage point moved dilutes object temperature on both sides; below roughly a fifth of traffic, a platform’s cache runs cool enough that its hit ratio visibly lags, so very lopsided “active-active” splits quietly buy the passive pattern’s weaknesses at active-active prices — the fragmentation arithmetic is in our analysis. The workhorse range is 60/40 to 80/20, moved deliberately.
Geography: split on evidence, not brochures
Regional assignment is where multi-CDN outperforms either platform alone — if the assignments follow evidence. Build the evidence per region you care about: RUM cuts by country and ASN per CDN (the dimensions you already collect in RUM), backed by controlled tests run the fair way from benchmarking CDNs; assign a region outright only where one platform leads consistently and materially — tens of milliseconds at the median, or clear QoE separation, sustained across weeks, not a single Tuesday’s test. Where the platforms tie, leave the region on the default ratio; assignment churn has costs (cache re-warming, config attention) that a two-millisecond win doesn’t pay for. Date-stamp every regional assignment with its evidence, because networks change — providers build out, peering shifts — and an assignment older than its evidence refresh cycle is due for re-measurement, not loyalty.
Workloads: each traffic class, best home
Traffic classes reward different platform strengths, and homing them deliberately is the highest-skill split. Video and large objects care about throughput, request pricing at segment scale, and media features — they often justify their own assignment, with the mid-stream switching option covered in multi-CDN for video. Dynamic and API traffic cares about TLS setup time, origin connectivity and compute at the edge; static assets are happy anywhere and make the ideal canary class for a newer platform. Two cautions: keep each hostname’s workload on one logical policy (splitting a single page’s assets across platforms multiplies connection setup for no gain — split by hostname/class boundaries, not within them), and remember every workload placed on a vendor-exclusive feature narrows tomorrow’s options — the lock-in ledger from the edge-compute guide applies to placement decisions too.
Running the split: review, rebalance, renew
A split is an operating decision, so give it operations: a monthly look at per-platform traffic against commit bands, hit ratio and origin load per platform (dilution drifting?), and the RUM cuts behind every geographic assignment; a quarterly rebalance where assignments whose evidence has aged get re-measured; and a pre-renewal review where the ratio becomes strategy — demonstrating three months of comfortably shifting ten points is the strongest sentence in the negotiation. Keep the split’s definition in the same intent-layer repo as everything else (config sync), so “who serves what and why” has one answer, with dates and evidence attached. And rehearse the extreme case — 100/0 in either direction — because the split you can collapse calmly is the one that makes failover day a weight change instead of an adventure.