The multi-CDN series covered plural edges; this is plural origins: two or more origin regions behind your delivery layer, for latency, for resilience, or because compliance planted data in specific geographies. The edge is the natural traffic director, and the configuration details decide whether failover is a non-event or a thundering mess.
The topology menu
Active-passive: one region serves, the other warms; edge health checks gate the switch. Active-active by geography: each edge region fetches its nearest origin, halving miss latency and pinning data gravity where compliance wants it. Active-active with failover: nearest-origin preference plus automatic spillover on failure. Every serious CDN supports origin groups with these semantics; the vendor vocabulary differs, the topology math does not.
Health checking, honestly
Failover quality is health-check quality. Check the thing that matters (a synthetic transaction touching the datastore, not TCP port liveness), from the vantage that matters (the edge’s own probes, per region, because your origin can be healthy from your office and unreachable from Singapore), at frequencies that balance detection speed against probe load. Design the flap-damping consciously: thresholds and cool-downs so a jittery origin does not oscillate traffic, with the oscillation itself alarmed as a distinct signal.
The compliance-driven variant deserves its own note because it inverts the failure logic: when data residency rules pin certain users’ data to certain regions, failover is not a free resilience choice, spilling EU traffic to a US origin may be a regulatory event, not a recovery. Estates in this position design partitioned failure domains (EU fails within EU capacity), encode jurisdiction into cache keys and routing policy, and document degradation modes legal has actually approved: serve stale from the compliant region (our stale-if-error machinery, promoted to compliance tooling) rather than fresh from the wrong one. It is a rare and pleasing case where aggressive cache staleness is the legally conservative option, and estates that pre-decide it avoid improvising jurisprudence mid-incident.
The traps
Cache-key contamination: if region-specific responses (currency, inventory) cache under region-blind keys, failover serves region A’s truth to region B’s users; keys must encode whatever origins legitimately vary. Thundering failover: a failed region’s entire miss load arrives at the survivor instantly, size the survivor for it or shed deliberately (the shield article’s arithmetic, doubled). Split-brain writes: delivery-layer failover moves reads gracefully, but write traffic needs application-level consensus about who is primary, an edge cannot referee your database. And the quiet one: failback, returning traffic after recovery deserves the same staging as failover, because a cold-cached recovered region is a latency event of its own.
In practice
Codify the topology in config-as-code (our canary article’s pipeline applies), rehearse regional failure quarterly with the DNS-decay lessons in mind, verify key hygiene with region-labeled synthetic objects, and watch miss-latency percentiles per edge region as the standing signal that origin selection is doing its geographic job. Plural origins are a maturity milestone; failover rehearsal is the license.
Origin-topology reviews here include the failover rehearsal and the key-hygiene verification. Split-brain findings are common and cheap to fix early.