CDN Routing Algorithms: Latency-Based, Geolocation, and Weighted Routing

Not all CDN requests should take the same path. The routing algorithm that maps a user to an edge PoP or origin determines Time to First Byte (TTFB), cache hit ratio, compliance posture, and even your monthly bill. Choosing between latency-based, geolocation, and weighted routing is not about picking a winner — it is about matching the algorithm to the workload.

Modern CDNs like CloudFront, Akamai, Fastly, and Cloudflare all expose some form of intelligent DNS or Anycast routing. Under the hood, three foundational strategies do most of the work. Understanding their trade-offs lets you design for performance without breaking localization or deployment safety.

1. How CDN Request Routing Actually Works

Before comparing algorithms, it helps to recall where routing happens. For most CDNs, the decision starts at DNS. When a user requests cdn.example.com, the authoritative DNS — often integrated with the CDN — returns an IP address for the optimal edge. That decision can be informed by EDNS Client Subnet (ECS), active health checks, BGP Anycast, and real-time latency probes.

Some providers extend routing to the application layer. Once the TCP/TLS connection lands at an edge, layer-7 logic can re-route to a shield PoP, a regional origin, or a different cache tier. If you are new to this flow, our primer on how CDN works and CDN DNS resolution explained covers the full request lifecycle from recursive resolver to edge cache.

Three signals dominate routing policy:

• Network performance: Measured RTT, packet loss, and throughput between user subnet and edge.
• Geography and jurisdiction: Country, state, or continent derived from MaxMind/GeoIP and ECS.
• Operational intent: Explicit weights you set for A/B tests, migrations, or cost control.

Each algorithm prioritizes a different signal.

2. Latency-Based Routing: Optimizing for Real Network Conditions

Latency-based routing (LBR) answers one question: which endpoint will serve this user fastest right now? Instead of assuming the geographically closest PoP is fastest, the CDN continuously measures round-trip time from probe networks and, when ECS is available, from actual resolver subnets.

AWS Route 53, for example, maintains latency tables between AWS regions and client subnets. Anycast CDNs like Cloudflare and Akamai achieve a similar effect at the network layer via BGP — the packet naturally lands at the PoP with the shortest AS path, which strongly correlates with latency.

How it works in practice

• The CDN runs synthetic probes (and aggregates real user monitoring data) to build a latency map.
• When a DNS query arrives, the authoritative DNS looks up the client subnet and returns the record with the lowest recent RTT.
• Health checks remove unhealthy PoPs from consideration, automatically failing over to the next-best latency target.

Best for Global SaaS, media streaming, APIs, and any workload where TTFB directly impacts revenue or UX.

Strengths and limitations

LBR excels when network topology is non-intuitive. A user in Berlin may get lower latency from Amsterdam than from Frankfurt if peering between their ISP and the Frankfurt PoP is congested. Geographic distance alone would miss that.

The trade-off is non-determinism. You cannot guarantee a German user stays in Germany, which matters for data residency. LBR also requires sufficient measurement density; in regions with sparse probes, decisions may be stale. Pairing LBR with CDN security controls like origin shielding and signed requests ensures that performance routing does not weaken your security posture.

# Create two latency records for the same name
# Users are routed to the region with lowest latency to them

aws route53 change-resource-record-sets --hosted-zone-id Z12345 \
--change-batch '{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "cdn.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1",
        "Region": "us-east-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "52.85.10.1"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "cdn.example.com",
        "Type": "A",
        "SetIdentifier": "eu-central-1",
        "Region": "eu-central-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "52.85.20.1"}]
      }
    }
  ]
}'

3. Geolocation Routing: Control by Borders

Geolocation (or geoproximity) routing maps users to endpoints based on their inferred location — typically country, subdivision, or continent — not network speed. If latency routing asks “what’s fastest?”, geolocation asks “where are you legally or commercially supposed to be served from?”

This is essential for three scenarios: regulatory compliance (GDPR, data localization in Russia, China, or Brazil), content licensing (sports streaming rights are sold per country), and localization (serving language-specific origins or pricing).

Implementation details

Most DNS providers let you define a default record plus overrides per geography. For example:

• Default → us-east-1 (global fallback)
• Europe → eu-central-1 + eu-west-1
• Germany → eu-central-1 (Frankfurt) with more specific priority
• China → china-north-1 via a separate CDN partner

Resolution relies on GeoIP databases and ECS. Accuracy is generally 95%+ at country level but drops at city level, especially for mobile carriers and VPN users. Always provide a sensible default and monitor for UNKNOWN geo lookups.

Geolocation routing pairs naturally with edge personalization. A retailer can route French users to a PoP that caches fr-FR pricing and inventory, reducing origin fetches. See our guide to CDN for ecommerce for patterns on locale-aware caching and price localization.

# Conceptual: Route by country using Worker + geolocation header
# Cloudflare adds cf-ipcountry automatically

export default {
  async fetch(request) {
    const country = request.cf.country; // e.g., "DE", "US", "JP"
    const euOrigins = ["eu-origin.example.com"];
    const usOrigins = ["us-origin.example.com"];

    // Enforce data residency for EU
    if (["DE","FR","IT","ES","NL","PL"].includes(country)) {
      return fetch(request, { backend: euOrigins[0] });
    }
    return fetch(request, { backend: usOrigins[0] });
  }
}

When not to use it

If you enforce geolocation too rigidly, users near borders or on multinational ISPs may suffer. A user in Strasbourg, France, physically closer to a Frankfurt PoP, might be forced to a Paris PoP because of country policy, adding 15-25 ms. For latency-sensitive APIs, prefer latency routing and enforce residency at the origin or storage layer instead.

4. Weighted Routing: Precision Traffic Shaping

Weighted routing distributes traffic by ratio, regardless of latency or location. You assign each endpoint a weight (e.g., 0-255), and the CDN returns answers proportionally. A weight of 80 vs. 20 means ~80% of queries resolve to endpoint A and 20% to endpoint B over time.

This is not a performance algorithm — it is an operational one. Its power is control.

Core use cases

• Canary and blue-green deployments: Shift 5% of traffic to a new origin or edge function, validate error rates, then ramp to 50/50 and 100%.
• Capacity and cost management: Gradually migrate from one CDN provider or origin region to another without DNS TTL pain.
• A/B testing at the edge: Split users between two cache behaviors or image optimization pipelines.
• Failover with bias: Keep 90% on primary, 10% warm on secondary to keep caches hot. See CDN cost optimization for how warm secondary caches reduce origin egress during failover.

Weights are deterministic in aggregate but random per query, so a single user may flip between endpoints unless you add stickiness (e.g., via a cookie or consistent hashing at the edge).

{
  "Name": "api.example.com",
  "Type": "A",
  "SetIdentifier": "api-v1-stable",
  "Weight": 90,
  "TTL": 30,
  "ResourceRecords": [{"Value": "203.0.113.10"}]
}
{
  "Name": "api.example.com",
  "Type": "A",
  "SetIdentifier": "api-v2-canary",
  "Weight": 10,
  "TTL": 30,
  "ResourceRecords": [{"Value": "203.0.113.20"}]
}
# 90% stable, 10% canary — adjust weights to promote or rollback instantly

Weighted routing shines when combined with health checks. If the canary fails health checks, its weight is effectively zeroed out, preventing user impact. Set low TTLs (30-60s) during migrations so weight changes propagate quickly.

5. Head-to-Head

6. Hybrid Architectures: The Production Standard

Rarely will one algorithm suffice. Leading CDN architectures nest them:

1. Top level — Geolocation for compliance: Route EU users to EU PoPs, US users to US PoPs, and APAC to APAC. This satisfies legal requirements before performance is considered.
2. Mid level — Latency within region: Inside EU, use latency-based routing between Frankfurt, Amsterdam, and Paris PoPs. This squeezes out the last 10-20 ms without violating borders.
3. Bottom level — Weighted for safety: Within each PoP or origin group, split traffic 95/5 between stable and canary origins. Combine with health checks and cache invalidation strategies to ensure new code does not serve stale content.

Example: A global video platform routes by geolocation to respect licensing, then by latency to the nearest regional shield, then by weight to gradually roll out a new transcoding pipeline. If the canary error rate exceeds 1%, weight is set to 0 and the shield cache absorbs the fallback without origin thundering herd.

When designing hybrids, keep DNS record complexity manageable. Most providers limit you to ~100 records per name. Use alias records, traffic steering policies, or edge workers to encapsulate logic rather than creating hundreds of fine-grained geo records.

7. Choosing the Right Algorithm: Decision Checklist

Ask these four questions before committing:

• Do you have jurisdictional constraints? If yes, start with geolocation. No performance gain justifies a compliance violation.
• Is TTFB your primary KPI? For APIs, checkout flows, and dynamic personalization, latency-based routing wins.
• Are you deploying or migrating? Any change to origins, edge logic, or providers should use weighted routing with low TTLs and automated health checks.
• How is your cache partitioned? Geolocation and weighted splits fragment cache. Ensure your cache key includes locale or version if needed, or you will see hit ratio drops of 15-30% during splits.

Finally, measure. Instrument Real User Monitoring (RUM) for p50, p90, and p95 TTFB by routing policy, not just by PoP. Compare the same user cohort before and after a routing change. A 12 ms p50 improvement that increases p95 by 40 ms is not a win for tail latency-sensitive workloads.

Routing is not set-and-forget. Networks evolve, GeoIP databases drift, and weights need tuning. Review latency maps monthly and audit geo overrides quarterly — especially after ISP mergers or new submarine cables go live in your key markets.