Global Edge Architecture: Routing, Caching, Origin Resilience, and Scale

Published

Jul 14, 2026

Updated

Jul 15, 2026

Reading time

13 min read

A nearby point of presence improves delivery latency; it does not make a distant, saturated, or inconsistent data authority disappear. Global edge architecture therefore begins with user journeys and states where each read, write, and failover decision is allowed to happen. At the scale a managed edge-orchestration layer runs at — dozens of routes, several provider networks, and two or more authoritative regions — that discipline only holds if it is enforced the same way everywhere and observed from one place; otherwise the fastest edge in the world will still fail over into the wrong region.

Scenario: Acme Shop serves EU and US customers without moving authority by accident

Acme Shop uses regional edge delivery and public catalog caches in Europe and the United States. EU customer-profile data remains in Acme's EU authority; US profile data remains in the US authority. Product catalog reads use regional replicas with a disclosed freshness target. Checkout writes always go to the customer's home authority. During a US application-region outage, Acme can serve public catalog pages from cache and can fail US checkout only to a prevalidated US standby that has the required payment and data dependencies. It does not fail US personal data to Europe merely because Europe is healthy. Acme also treats its authoritative DNS and its edge-level traffic steering as two different control planes with two different recovery speeds: the edge absorbs a single site's failure in seconds, while moving an entire region to a different network or provider is a slower, reviewed DNS change.

1. Publish a global edge architecture routing and data-authority table

DNS is a slow control plane because resolvers retain answers beyond a change. Use it for stable entry and provider selection; use the edge for route-level decisions based on path, cache state, and validated application health. Document the route contract before configuring either layer.

If a route depends on residency or contractual processing commitments, encode that as a routing invariant and monitor it. IP geolocation is a delivery signal, not proof of a person's location or a lawful data-routing decision.

DNS carries a second, less obvious risk during an incident: resolvers are required to cache resolution failures, not just answers. If an authoritative name server becomes briefly unreachable, a recursive resolver can hold that failure for the duration of its negative-cache window, which extends an outage past the moment the authoritative side actually recovers, and can drive a large retry storm onto the wider DNS system when many resolvers re-query at once (RFC 9520). Treat the availability of the authoritative DNS path itself as a monitored dependency, distinct from the records it serves.

2. Choose a global traffic routing method: anycast, DNS steering, or both

Two different mechanisms actually move traffic globally, and they fail on different timescales:

• DNS-based steering changes which address a resolver hands back. It is simple to reason about and works for any transport, but a change only takes effect as resolvers expire their cached answers — typically minutes, longer if a resolver misbehaves or caches a resolution failure as described above. Lower a record's TTL before a planned change, not during an incident; a TTL lowered after resolvers already cached the old value has no retroactive effect.
• Anycast routing advertises the same address from every edge site and lets BGP deliver each packet to a topologically close, healthy site. Convergence after a withdrawn route is usually seconds rather than minutes, which is why most CDN and DNS-resolver networks run anycast underneath their global traffic routing. The tradeoff is mid-session re-routing: if BGP reconverges during a long-lived connection such as a WebSocket, later packets can land on a site with no record of that connection's state, breaking it even though every individual hop "succeeded" (RFC 4786).

Acme uses both, deliberately, and does not let one stand in for the other. Anycast at the edge layer gives it sub-second protection against a single site failing. DNS-based provider selection is reserved for the slow, reviewed decision to move a region's entry point to a different network or provider. A BGP-level failover never gets to make a data-authority decision; that stays governed by the table in the previous section.

3. Budget capacity before moving traffic

Failover is a capacity decision. If the primary receives P requests/s, the standby must support the traffic share it will receive plus headroom for cache misses and recovery work:

required standby capacity = P x failover share x (1 + headroom)

For 800 checkout requests/s, a 50% planned shift, and 30% headroom, Acme validates at least 800 x 0.5 x 1.3 = 520 requests/s of safe standby capacity. Validate database pools, payment-provider quotas, connection limits, TLS, WAF/rate policies, and queue workers at the same time. A healthy HTTP listener without those dependencies is not a failover target.

route: /checkout
primary: us-east-authority
standby: us-central-authority
steering:
  trigger: journey-health-check
  unhealthy-after: 3 consecutive failures
  shift: 10 percent every 5 minutes
  minimum-dwell: 15 minutes
  recovery: 3 consecutive healthy checks plus capacity review
guards:
  required-deploy-version: checkout-2026-07-14
  required-data-authority: US
  direct-origin-access: denied

trace_id=4bf92f... route=/checkout client_region=US
selected_origin=us-east-authority steering=primary
authority=US cache_status=BYPASS
health=healthy deployment=checkout-2026-07-14

4. Design public cache layers for origin resilience

Keep browser, edge, shield, and application caches distinct. Acme caches only public catalog representations, with a key based on normalized path, approved locale, and documented variant. It uses request collapsing at the shield so an expiry does not create hundreds of identical origin fetches.

At an edge hit ratio H, a public route at R requests/s sends roughly R x (1 - H) initial requests/s upstream. The calculation is a planning baseline, not permission to exceed origin concurrency. A cold cache, purge, or routing shift reduces H, so test those events at the expected traffic distribution.

Origin resilience also comes from what the cache is allowed to do when the origin is slow or failing, not only from the hit ratio. Acme's catalog responses carry Cache-Control: max-age=120, stale-while-revalidate=300, stale-if-error=3600. stale-while-revalidate lets the edge serve the last fresh-enough copy while it revalidates in the background, hiding origin latency from the customer; stale-if-error lets the edge keep serving that last good copy for up to an hour if the origin starts returning errors, which is the directive that actually protects a page during an origin incident. Both are part of RFC 9111 and only help if every layer between edge and browser honors them — a shield, application cache, or intermediate proxy that strips or ignores the directive silently removes the protection it was meant to provide.

Private account, order, authorization, and checkout responses are not shared-cached. The origin denies direct traffic, accepts only the trusted edge connection, and replaces client-supplied forwarding headers.

5. Exercise a US failover without violating EU authority

Use a controlled test window and a non-destructive checkout test transaction. Do not simulate failure by disabling broad security controls or by sending unsafe traffic.

1. Confirm the EU and US authority map, deployment version, certificate, edge-to-origin identity, and standby capacity evidence.
2. Establish baseline p95, error rate, cache-hit ratio, queue age, order acceptance, and payment-provider responses by region.
3. Make the US primary's checkout journey health check fail in the approved exercise scope only.
4. Shift 10% of US checkout traffic to the US standby. Hold for the dwell period, then continue only if the success criteria hold.
5. Verify EU account and checkout traffic never selects a US destination; verify US account data remains in the US authority.
6. If any leg of the path uses anycast, watch for catchment changes during the shift — a site announcing or withdrawing a route mid-test can re-home in-flight, long-lived connections to a node with no session state. Confirm the client-visible effect is a clean retry, not a silent stall or a duplicate submission.
7. Restore the US primary, wait for recovery hysteresis, and shift traffic back gradually. Preserve the evidence and decision log.

Troubleshooting

Related guides

• Edge Compute Architecture
• Kubernetes Multi-Region Edge
• Distributed Systems Latency Budgets

Authoritative references

• Google SRE Book: Addressing Cascading Failures
• Google SRE Workbook: Managing Critical State
• IETF RFC 9111: HTTP Caching
• IETF RFC 4786: Operation of Anycast Services (BCP 126)
• IETF RFC 9520: Negative Caching of DNS Resolution Failures
• Microsoft Azure Architecture Center: Deployment Stamps pattern
• OpenTelemetry semantic conventions