Data Locality & Geo-Distribution Lab (Interactive)
Route a Sydney user to a Virginia origin and watch 200,000 km/s physics dominate every RTT you have not moved to the edge. Compute fiber roundtrips from real geography, then add edge CDN caching or local read replicas to shrink time-to-first-byte.
Speed-of-Light Latency Budget Planner
Photons in glass move at ~200,000 km/s. No optimization beats physics — only locality does.
How It Works Under the Hood
Light in silica fiber moves at roughly 200,000 km/s and subsea cables detour 1.5-2x beyond great-circle distance, so London-Sydney is a hard ~280 ms floor no code can beat. A legacy first visit pays four roundtrips — DNS, TCP, TLS, GET — nearly a full second before the first byte. Data locality defeats it from two directions: move data to users with 300+ edge PoPs running TLS termination and LiteFS or Aurora Global read replicas, or move compute to data for analytics workloads, while GDPR geo-partitioning constrains which users may get which replica.
Core Architectural Principles
- Roundtrip ≈ fiber km ÷ 200,000 km/s × 2 — NYC-London ~75 ms, SF-Tokyo ~110 ms, fixed by physics.
- Edge PoPs terminate TLS in ~4 ms locally and reuse pre-warmed private-backbone connections to origin.
- Reads answer from local replicas in under 6 ms; writes forward asynchronously and accept ~1 s staleness.
Open global-latency questions with physics: "Light in fiber is 200,000 km/s, so Sydney to Virginia is a ~220 ms floor; I will terminate TLS at edge PoPs and serve reads from regional replicas." Close with GDPR geo-partitioning as a compliance driver, not just a performance one — that pairing is staff-level.
Edge locality buys sub-15 ms reads at the cost of replication lag, cross-region write complexity, and a multiple of single-region infrastructure spend.