Everything else in the multi-CDN library builds toward this: real users continuously measuring every platform from every network, and traffic automatically flowing to whichever platform serves each network best. Closed properly, the loop makes two CDNs faster than either alone. Closed carelessly, it oscillates, chases noise, and turns your steering layer into the least predictable component you run. The difference is engineering discipline on three sides — data, decisions, actuation — plus guardrails.
The loop, and why RUM is the honest signal
The loop has four stages: users on both platforms generate performance beacons; a pipeline aggregates them into per-network, per-platform scores; decision rules convert score gaps into routing intentions; and an actuation layer — DNS weights, steering responses, player logic — makes traffic follow. RUM is the honest signal because it measures the only thing that matters — real clients, real networks, real content — where synthetics measure a few clean vantage points; but honesty costs statistics: RUM is noisy, unevenly distributed across networks, and only exists for platforms currently receiving traffic. That last property is load-bearing: a platform steered to zero goes dark to measurement, so the loop must always keep a measurement floor of traffic on every platform — the first guardrail, and the reason “winner takes all” is never the right rule. Commercial products (RUM-fed managed DNS, orchestrators — the field in our comparison) package this loop; understanding it is what lets you configure or replace them well.
The data side: cuts, samples, freshness
The score that drives steering is a cut: metric × network × platform × window. Metric: for web, TTFB or a composite load metric from your RUM deployment; for video, the QoE numbers from the QoE guide — and prefer percentiles (p75) over means, which one bad session can drag. Network: ASN is the working granularity — country is too coarse (one country contains great and terrible paths to the same CDN), per-user too sparse. Then impose statistical hygiene before any number reaches a decision: minimum sample counts per cell (a cell with forty sessions is an anecdote — steer only on cells with enough data that the gap exceeds the noise), freshness windows short enough to react but long enough to fill (an hour or two for busy ASNs; longer, sparser tails fall back to coarser cuts), and outlier handling so one device model’s pathology doesn’t reroute a nation. The pipeline output worth building: a per-ASN scoreboard, each cell scored, sampled, aged — and marked steerable or insufficient-data.
The decision side: rules, damping, floors
Decision rules turn scoreboard into intent, and every rule exists to prevent a failure mode. Significance threshold: steer only when the gap is material (say, p75 differences beyond both a relative and an absolute floor) — prevents chasing measurement noise. Hysteresis: the gap required to switch back exceeds the gap that switched — prevents flapping when platforms are genuinely close. Damping: move weights gradually (shift a cohort 20 points, remeasure, continue) rather than all at once — prevents self-inflicted stampedes, and respects that moving traffic changes cache heat, which changes the measurements (the loop’s feedback is real: a platform can look slow because it is cold, then warm as traffic arrives — damped moves let the system find its equilibrium instead of orbiting it). Floors and pins: the measurement floor from section one; commercial floors where commits must be fed (coordination with the split strategy); and manual pins for networks under known events. Write the rules as configuration with history, not tribal knowledge — “why did AS7922 move on Tuesday” must have a queryable answer.
Actuation: DNS, steering servers, players
Match the actuator to the traffic. Web estates actuate through the managed-DNS layer — per-geo or per-ASN policies fed by your scores via API, on the steering foundation already built, inheriting DNS’s granularity (per resolver) and latency (per TTL): fine for gradual optimization, honest about its limits during fast incidents. Video estates actuate closer to the user — the content-steering server or player selection logic from the video setup consumes the same scoreboard and moves sessions in seconds, per network, mid-stream. Most mature estates run both: DNS-layer steering as the broad, slow optimizer; client-layer steering where the workload supports it, as the fast, fine one. Whichever actuators you run, they take intentions from one decision layer — two independent optimizers steering the same traffic against each other is the distributed-systems bug you get to keep.
Guardrails, observability and the maturity path
Treat the loop as the control system it is. Guardrails: a maximum rate of total traffic movement per hour; a deadman default (steering data stale → fall back to static weights, never to zero); change caps per network; and a big red switch to static configuration, rehearsed, for the day the optimizer itself misbehaves. Observability: dashboard the loop’s own behaviour — moves per day, oscillation detection (a cohort switching repeatedly is the smell), realized QoE before/after each move — because a control system without self-observation degrades silently; and let the realized-improvement number justify the loop’s existence quarterly, in the spirit of every honest alert in the monitoring guide. Maturity path: start with the scoreboard read by humans at a weekly rebalance (closing the loop manually is already most of the value); automate per-region weights next; per-ASN and client-layer last. The estates that get here find the endgame pleasantly dull: two platforms, one scoreboard, traffic quietly pooling wherever users are best served — which was the entire promise of the second CDN, finally kept.