Skip to content

PATTERN Cited by 1 source

Region hint for anycast origins

Pattern

When automated latency probing cannot determine the true location of an origin (because the origin IP is anycast or regional unicast), expose a simple region hint knob that lets the operator declare which cloud region the origin actually lives in. The CDN then uses this hint — combined with continuously updated cloud-provider IP-range mappings — to select the optimal upper tier.

Shape

Operator declares: origin 203.0.113.5 → aws:us-east-1
System maps:       aws:us-east-1 → [subnet list from AWS ip-ranges.json]
System selects:    best upper tier per weighted-voting algorithm

Why This Pattern Exists

Fully automated tier selection works for unicast origins (clear latency winner) but fails for anycast origins (ambiguous probes). Rather than building increasingly complex heuristics to infer cloud region from network behaviour, the pattern accepts that some knowledge is external and lets the operator provide it through a simple declaration.

Design Properties

  • Minimal operator burden: one field per origin IP (cloud-provider:region-name).
  • Composable with automation: the hint feeds into the same weighted-voting pipeline that handles unicast origins.
  • Bulk-editable: API, Terraform, and dashboard bulk-edit support.
  • Fail-safe: without a hint, the system falls back to multiple upper tiers (safe but suboptimal), not a single wrong tier.

When to Apply

  • Origin is behind a cloud provider's anycast or regional unicast load balancer.
  • Latency probes return ambiguous results (many data centers appear equally close).
  • The operator knows which cloud region their backend actually runs in.

Seen in

Last updated · 575 distilled / 1,757 read