Why a Singapore User Feels Your Frankfurt Server: Network Latency Between Regions Explained

The Physics Floor: Why 5 µs/km Is Non-Negotiable

Propagation delay in silica fiber runs about 5 microseconds per kilometer, while free-space propagation clocks in near 3.33 µs/km. The gap between them matters: your packets move through glass, not vacuum. A 200-kilometer fiber span incurs approximately 1 millisecond of delay before the first router sees the frame. This is the baseline that no engineering cleverness can compress.

The route compounds the problem. Fiber paths rarely follow straight lines. A study puts the typical network path at 1.2 to 1.5 times the straight-line distance between endpoints. A Singapore-to-Frankfurt great-circle distance of roughly 10,200 kilometers becomes 12,240 to 15,300 kilometers of actual glass. At 5 µs/km, that translates to 61 to 76 milliseconds one way, 122 to 152 milliseconds round trip—before congestion, before queuing, before any application-layer ceremony.

Research confirms this bound: measured latency is generally less than twice the ideal latency, and real distance remains a good estimator between data centers. The physics floor is knowable. Everything above it is architecture.

Where the Extra Milliseconds Hide

Cloudflare's CDN documentation notes that latency from New York to Singapore grows from total distance and from the processing each router performs along the way. Every hop adds its own contribution: forwarding decision, queueing delay, serialization. Studies identify queueing and buffering as significant additive factors alongside raw propagation.

Circuitous routing can dwarf these effects. The same arXiv paper cites Tunis to Lagos: lack of direct submarine cables forces traffic around the continent, producing roughly 150 ms RTT against a theoretical minimum of 50 ms. The physical distance did not change. The available paths did. Internet architecture is geography constrained by investment and peering, not by physics alone.

This distinction matters for estimation. When you eyeball two cities on a map, you capture only the crow-flies component. The actual fiber route—dictated by cable landing stations, peering relationships, and backbone topology—sets the real floor.

One User Action, Multiple Round Trips

RTT measures the complete there-and-back, not the one-way journey. IBM's latency explainer notes that ping captures roughly double the one-way latency. This matters because user-visible delays stack.

A single HTTPS request entails DNS resolution (often cached, sometimes not), TCP handshake, TLS negotiation, and only then the application request and response. Each step that blocks on the network adds its own RTT. A Cornell working paper on the latency of cloud services found that measured latency is generally less than twice the ideal latency—suggesting that real-world RTT captures propagation plus moderate architectural overhead, not multiplication by large factors. But sequential blocking requests multiply exposure. A page with six critical serial dependencies can pay six times the base RTT before rendering begins.

Engineers sometimes measure from their laptops, confuse one-way and round-trip figures, and underestimate what users in other regions experience. The numbers from your terminal are not representative.

What CDNs and Anycast Actually Move

Content delivery networks do not abolish distance. They relocate the first hop. Cloudflare's measurement methodology captures median TCP RTT per /24 subnet, explicitly focusing on anycast network performance while excluding host software differences. Research groups clients by routable prefix, treats RTT to that prefix as representative, and periodically refreshes measurements to select the lowest-latency node.

BGP-based anycast routing determines which data center receives a request based on available paths between client and CDN. The user in Singapore hits a Singapore edge, not Frankfurt—provided the content is cacheable. For reads, this works. For writes, the origin still matters. IBM's guidance on reducing latency mentions moving servers and databases geographically closer to users, and using CDNs to store content closer. The distinction is implicit: CDNs cache; origins serve mutations.

Anycast performance depends on routing paths. Not every user lands at the geographically nearest POP. BGP path selection—driven by AS path length, MED, local preference—can send a Singapore user to Tokyo or Hong Kong if those routes appear shorter to the network. Measured RTT from user prefixes reveals the true topology.

Shrinking the Felt Distance

Operational levers fall into three categories: terminate closer, replicate reads, and reduce sequential round trips. Google refreshes RTT measurements periodically to keep CDN node selection current. Cloudflare's /24 subnet aggregation captures actual network behavior rather than geographic assumption.

TCP throughput is inversely proportional to RTT, according to the arXiv analysis. Users and testing clients naturally seek the closest measurement server—not out of preference, but because distance costs time. Application designers can exploit this: parallelize where possible, pipeline where sequential, and never chain blocking requests across high-latency links without measurement.

The 5 µs/km floor is fixed. Everything above it is negotiable.

The Decision Rule: Measure From Your Users, Not Your Laptop

Adding a region carries operational cost and consistency complexity. The decision should rest on user-weighted measured RTT, not map intuition. One methodology—grouping by routable prefix, treating RTT as representative, refreshing periodically—provides the template. Cloudflare's /24 subnet aggregation offers the granularity.

Measure from where your users are. A laptop in Frankfurt tells you nothing about the experience in São Paulo or Jakarta. The Cornell research confirms that real distance predicts latency well, but only real distance through actual paths. BGP tables, cable maps, and peering agreements shape those paths in ways no globe can show.

The arithmetic is straightforward: propagation floor plus architectural overhead, multiplied by request count and sequential dependencies. When user volume in a region justifies the overhead of replication—and when measured RTT from those user prefixes shows sustained pain—the region merits consideration. Not before.