Geo-Routing

The Problem

 users in Tokyo hitting a US-East server:

 RTT ~150ms+ per round trip → every request crawls.
 also: EU user data landing in US storage = compliance problem.

 GEO-ROUTING: route each user to the nearest/most-appropriate
 region automatically.

 [Tokyo user] ──► [APAC region]   ~30ms ✓
 [Berlin user]──► [EU region]     ~20ms ✓ + data residency ✓

The Mechanisms

 GEO-DNS (route53 geolocation, etc.):
   same hostname; resolver answers DIFFERENT IPs by
   caller's location:
     app.example.com  →  EU query → EU LB IP
                      →  ASIA query → APAC LB IP

 LATENCY-BASED routing: measures actual RTT from vantage
   points, picks fastest (better than geography guesswork)

 ANYCAST: same IP advertised from many regions;
   BGP delivers to nearest — simplest, used by big CDNs/DNS

 WEIGHTED/FAILOVER policies: traffic splits or standby pools.

 layered reality: DNS geo-routes to REGION,
 then CDN/LB handles intra-region edge selection.

The Caching Layer of Lies: TTLs

 DNS answers are CACHED by resolvers worldwide:

 TTL 1 hour → region failure takes up to an HOUR to
              propagate around the globe ⚠

 TTL tradeoff:
   long TTL:  fewer DNS queries, stable, slow failover
   short TTL: fast rerouting, more resolver load,
              some resolvers IGNORE low TTLs anyway!

 practical posture:
 - NORMAL operation: TTL minutes-class (60–300s)
 - FAILOVER records: pre-lowered TTLs on the specific records
 - don't rely on DNS alone: global-LB health-check routing
   (anycast-fronted) reacts in seconds without waiting
   for cache expiry

Session Affinity Complications

 routed-to-nearest breaks when users MOVE or regions FAIL:

 - traveling user hops regions mid-session → state?
 - failed region's users re-route → sessions lost?

 design answers:
 □ STATELESS app tier + centralized/global session store
 □ STICKY-BY-DATA model: user's DATA homed per region;
   requests carry routing hints (cookies with region stamp)
 □ failover UX: re-auth acceptable if honest about it

 the deeper pattern: geo-routing decides WHERE COMPUTE happens;
 data-homing (next lessons) decides where STATE lives.
 keep those decisions aligned or pay cross-region latency
 on every request-data meeting.

Goal	Best-fit mechanism
Pure latency	anycast / latency-based
Data residency	geo-DNS with policy rules
Fast failover	health-checked global LB over short-TTL
Canary by geography	weighted per-region

Interview Framing

“Route global users optimally across three regions” scored shape: mechanism comparison (geo-DNS vs latency-based vs anycast), TTL-vs-failover-speed tension handled via health-checked LB layer, session-affinity answer tied to stateless design + data-homing, compliance routing mentioned. The TTL-honesty (“DNS alone is too slow for real failover”) is the practitioner tell.