How to choose a server location: latency, routes and the law

Location is one of the few infrastructure decisions you cannot fix later with a faster CPU. The distance between your server and your users sets a floor on latency that no hardware removes, and the country your data sits in decides which rules apply to it. Here is how to reason about both, using the same formula as our latency estimates.

The physics: about 200 km per millisecond

Light travels through optical fiber at roughly two-thirds of its speed in a vacuum: about 200,000 km per second, or 200 km per millisecond. A request and its answer cross the distance twice, so every 1,000 km between you and your users adds at least 10 ms of round-trip time (RTT).

Real paths are longer than the map. Cables follow coastlines, railways and roads; traffic changes networks at specific interconnection points; and BGP chooses routes by business policy, not geography. Routers add a little delay at every hop. Our latency figures therefore multiply the great-circle distance by 1.3 for routing detours, divide by 200 km/ms, double the result for the round trip and add 2 ms for equipment:

estimated RTT (ms) = 2 × (distance in km × 1.3 / 200) + 2

These are estimates, not measurements: congestion or an indirect route can add much more, and the return path can differ from the outgoing one.

Why round-trip time matters more than bandwidth

Most interactions on the internet are a series of round trips, and each one waits for the speed of light:

• Connection setup. A new HTTPS connection over TCP spends one round trip on the TCP handshake, one on a TLS 1.3 handshake and one on the request itself before the first byte of the response arrives. Three round trips at an estimated 20 ms take 60 ms; at 150 ms, they take 450 ms.
• TCP slow start. A fresh connection starts by sending about 10 packets (roughly 14 KB) and roughly doubles that each round trip. Delivering 1 MB this way takes around seven round trips whatever your port speed: about 140 ms at 20 ms RTT, more than a second at 150 ms.
• Pages and APIs. A page that loads HTML, then CSS, then fonts chains round trips. An API client that makes 20 sequential calls pays the RTT 20 times.
• Databases. Every query costs at least one round trip. A request that runs 30 queries one after another spends 30 RTTs waiting: negligible inside one location, where a round trip typically takes well under a millisecond, and 2.4 seconds at 80 ms.
• Games. RTT is the ping players see. The server’s tick rate decides how often the world updates; the ping decides how old each update is when it arrives.

This is why a server close to its users often feels faster than a more powerful one far away.

Start with your users, then your data

1. Find your users. Group your traffic or player base by country or metro area from your server logs, and weight each group by what matters to you: revenue, active players or contractual obligations.
2. Estimate the RTT from each group to each candidate location with the latency checker, and pick the location that keeps most of your weighted users within your target.
3. Put compute next to your data. If your database, object storage or the third-party APIs you call heavily live in one region, place your application servers there too. App-to-database chatter is usually more sensitive to latency than user-to-app traffic.
4. Split only when one location cannot serve everyone well. An audience spread across Europe, Asia and the Americas usually needs more than one location.

Internet exchanges and subsea cables

Two pieces of public infrastructure explain why some cities make better hubs than others.

Internet exchange points (IXPs) are places where networks hand traffic to each other directly. Where many networks meet, paths between them tend to be short. Europe shows it clearly: Frankfurt is home to DE-CIX, Amsterdam to AMS-IX and London to LINX, three of the largest internet exchanges in the world.

Subsea cables carry almost all traffic between continents, and they land in a handful of regions:

• New York is a classic landing region for transatlantic cables to the UK and continental Europe.
• Miami is a primary gateway between North America, the Caribbean and Latin America.
• Los Angeles and the rest of the US West Coast anchor many trans-Pacific routes to Asia and Oceania.
• Singapore links Southeast Asia with India, Australia, the Middle East and Europe.
• Tokyo sits at the Asian end of many trans-Pacific cables and is Japan’s main interconnection hub, an estimated 17 ms from Seoul.

DediJet’s network is multi-homed: each location connects to several transit providers over BGP, with redundant uplinks. Still, a well-connected city does not promise a short path to every user, which is why measuring matters.

The law: where your data lives

A server’s location also decides where your data physically sits, and regulations or contracts may care about that. Some facts to frame the conversation with your legal team:

• Location is not the whole story. The GDPR applies to organizations established in the EU, and to those that offer goods or services to people in the EU or monitor their behavior, wherever the server sits. Hosting in Frankfurt does not remove obligations, and hosting in New York does not avoid them.
• Transfers have rules. The GDPR, the UK GDPR, Singapore’s PDPA and Japan’s APPI all restrict sending personal data abroad unless the destination offers comparable protection or another safeguard applies, such as contractual clauses or consent.
• Contracts can be stricter than the law. Public-sector, health and finance customers may require data to stay in a given country or region.

When one location is not enough

• Regional servers. Game communities and SaaS products with users on several continents often run one server per region, each close to its users, and route people with GeoDNS or per-region hostnames such as eu.example.com.
• Asynchronous replication across regions. A synchronous commit waits at least one round trip for the replica: an estimated 135 ms between Frankfurt and Singapore. Keep synchronous replicas in the same location and replicate asynchronously to the distant one.
• Encrypted links between locations. The free private VLAN, available on request, connects your servers within one location. Between locations, traffic crosses the public internet, so protect it with WireGuard or IPsec.
• Backups somewhere else. Keep at least one copy of your backups outside the location of the primary server.
• The same hardware everywhere. The Ryzen 5 7600 and Ryzen 7 9700X are offered in all 8 locations, which keeps a multi-region fleet uniform.

Replication traffic between regions is not billed by the gigabyte either: every plan’s bandwidth is unmetered at its port speed.

Estimate, then measure

Start with the latency checker to shortlist locations from your users’ cities, then see what is in stock in each of our 8 locations. Once a server is running, measure the real path from where your users are:

mtr -rwc 50 203.0.113.10
ping -c 20 203.0.113.10

mtr combines traceroute and ping, so you can see where along the route delay or packet loss appears. Our network testing guide explains how to read the output. With monthly billing and no lock-in, moving to a better location later is a migration, not a contract negotiation.