Geo-Routing

Why Location Decides Architecture

 every user-facing decision starts with WHERE:

 - which edge serves this user?      (nearest = fastest)
 - which database region?            (data locality/residency)
 - which language/currency?          (geo-personalization)
 - is this region allowed content?   (licensing/compliance)

 geo-routing = the machinery answering these consistently.

Mechanism 1: DNS-Based Geo Steering

 authoritative DNS returns DIFFERENT answers by resolver location:

 dig www.app.com from Manila  →  edge.manila.example (1.2.3.4)
 dig www.app.com from Berlin  →  edge.frankfurt...  (5.6.7.8)

 properties:
 - happens BEFORE connection: zero request overhead
 - granularity limited to DNS resolver location, not true
   client location (resolver ≠ user sometimes — mobile networks!)
 - TTL-bound: changes propagate at DNS speed (minutes)

Mechanism 2: Anycast

 ONE IP announced from MANY datacenters; BGP routes each
 user to the nearest announcement point:

 same IP 104.16.0.1 advertised in 300 cities
 Manila user's packets naturally arrive in Manila
 (internet routing does the steering — no DNS tricks)

 properties:
 - no TTL/staleness concerns: routing is continuous
 - automatic failover: city offline → BGP reroutes neighbors
 - coarse granularity: nearest POP by network topology,
   not exact distance
 this is how the biggest CDNs route. boring and brilliant.

Mechanism 3: Latency-Based / Application-Layer

 smarter than pure geography: measure ACTUAL latency/RTT
 and steer to genuinely-fastest target:

 geo says Manila→Singapore; measurements say Singapore
 is congested today → steer to Tokyo instead.

 implemented by:
 - load balancers with RUM/synthetic latency data
 - CDN internal routing (their core competency)
 - app-layer: redirect/config APIs for region pinning

The Geo-Data Problem

 mapping IP → location has its own failure modes:

 - GeoIP databases lag reality; VPNs/proxies lie
 - mobile carriers route through distant gateways
 - accuracy ~city-level at best; never trust for security alone

 uses ranked by tolerance:
 ✓ cache/routing decisions    (wrong guess = slightly slower)
 ⚠ compliance gating          (needs careful fallback UX)
 ✗ authorization decisions    (combine with account settings)

Multi-Region Routing Shape

 [user] ──anycast/DNS──► [nearest edge]
                             │ miss/dynamic
                        [region LB]
                             │
                     [ regional stack ]
                     db-primary or local reads per region design
 
 the routing layer is what makes multi-region DEPLOYMENTS
 usable — own lessons cover the data replication behind it.

Interview Framing

“How do Asian users reach your US-hosted app fast?” expects: CDN edges via anycast as the default answer, DNS-steering for region selection when self-hosting, latency-based refinement as bonus, and the honest caveat about GeoIP accuracy. Distinguishing ANYCAST (routing-level, automatic) from DNS-GEO (lookup-time, configurable) marks real networking depth.