Pick a cloud region by measuring it, not by looking at a map

01The obvious answer

Drivio is a ride-hailing platform used in Karachi. Every booking, every driver offer and every wallet movement is a request to a backend, and a rider watching a search spinner feels each one. So the region that backend runs in is not an infrastructure detail — it is part of the product.

Look at a map of Google Cloud regions and the choice seems made for you: Mumbai (asia-south1) is the closest region to Karachi by a wide margin. That is where the backend first went.

02The measurement that could not tell regions apart

An early audit timed TCP connections to each region and got 25–35 ms for all of them. That looks like confirmation that any nearby region is fine. It is not a measurement of the region at all.

Google terminates connections at an anycast edge close to the user, wherever the service actually runs. A handshake to Mumbai, to Iowa and to Belgium is answered by the same nearby edge, equally fast. A TCP-connect number cannot tell two regions apart, so it cannot be used to choose between them.

03What we measured instead

We deployed a small service in each candidate region and measured time to first byte from Karachi — a request that has to reach code running in that region and come back. Three runs, eleven warm samples each, median shown (30 August 2026):

The nearest region on the map was the slowest region we tested — slower than Iowa, on the other side of the planet. Doha was thirteen times faster than Mumbai.

04Why the map was wrong

Network distance is set by where the cables go, not by geography. Pakistan has no direct internet peering with India, and every submarine cable that lands in Karachi runs west, into the Gulf. Traffic bound for Mumbai leaves Pakistan westward and is carried back east from somewhere else.

The effect is large enough to look like an error: from Karachi, Tokyo is 124 ms closer than Mumbai. The Gulf, which the cables reach directly, is the closest place on the network.

05Moving the database is not a setting

Moving the API was a redeploy. Moving the data was not: a Firestore database’s location is permanent, and functions triggered by database events must run in the database’s own region. So the database had to be copied out, deleted, recreated in Doha, and copied back.

• Every document was hashed field by field before the delete and again after the restore. 2,406 documents: none lost, none changed.
• A full walk of the database took 26 s against Mumbai and 5.7 sagainst Doha. Warm point reads now take a median of 51 ms.
• A new database starts with no security rules and no indexes. Deploying those is part of the move, not a follow-up.

One near-miss is worth recording. A first attempt stopped after the copy-out, but the configuration was updated as if the move had finished. A deploy on that belief would have deleted the working database triggers and failed to recreate them. The fix was a check that asks the cloud provider where each database actually is, run immediately before every deploy — rather than trusting two config files that agreed with each other and were both wrong.

06What to take from it

• Measure against a service running in the region, never a handshake and never a map.
• Measure from where your users are. The answer for Karachi is not the answer for Lahore-via-a-different-ISP, let alone for London.
• Event-driven code follows the data. Pick the database region first; it is the one you cannot change.
• Check the live state before a deploy, not the configuration that describes it.