skip to content

A mobile backend serves users a continent away and feels slow — what latency floor does that distance set, and what cannot fix it?

level: middleimportance: must knowfreq 70%

answer

  1. the floor is geography, not code
  2. about 200 km per millisecond in fibre
  3. real paths are longer than the map
  4. each dependent call pays it again
  5. only a shorter path lowers it

basics

~20 s

Distance fixes a round-trip floor: light in fibre travels about 200,000 km per second and real paths are longer than the map, so a far continent costs roughly a tenth of a second per round trip. Bigger machines and more instances cannot shorten it.

solid answer

~40 s

The floor is physics. Light in fibre covers roughly 200 km per millisecond, and real cable paths run well above the straight-line distance, so a user about 9,000 km away pays on the order of 60 ms each way and about 120 ms per round trip before your service does any work. Anything a request does *sequentially* multiplies that: six dependent calls back to the region is six round trips. What cannot fix it is anything inside the region — a larger machine family, more instances, faster storage, a rewritten handler. What can help is removing round trips from the path, doing independent work in parallel, or shortening the distance itself by serving those users from a region closer to them. Distance is the only one of those that changes the floor.

code

pseudocode · 20 lines
pseudocode
// signals in fibre: about 5 microseconds per kilometre
// pathFactor accounts for cable not running in a straight line
constant usPerKm = 5
constant pathFactor = 1.4

function roundTripMs(mapDistanceKm):
    fibreKm = mapDistanceKm * pathFactor
    oneWayMs = fibreKm * usPerKm / 1000
    return 2 * oneWayMs

function userWaitMs(mapDistanceKm, dependentCalls, serverWorkMs):
    return dependentCalls * roundTripMs(mapDistanceKm) + serverWorkMs

// user 9000 km away:
//   fibreKm   = 12600
//   oneWayMs  = 63
//   roundTrip = 126
// four dependent calls, 20 ms of server work:
//   userWait = 4 * 126 + 20 = 524 ms
// halving server work to 10 ms changes 524 to 514

go deeper

for a junior

Know that distance itself costs time and that nothing inside the region removes it. Roughly 200 km per millisecond in fibre, doubled for the return trip, is the number to carry.

for a middle

Explain the floor and its multiplier: the cost is per crossing, so sequential dependent calls and connection setup are what turn a floor into a complaint. Say which fixes touch the floor and which do not.

for a senior

Show the diagnosis: measure the same request from near and far, separate server duration from client-observed time, count crossings per user action, and check nothing has put the store on the other side of a regional boundary.

for a principal

Own the placement consequence — whether the product can serve two distant geographies from one region at all, and what accepting a permanent floor for one market is worth against the cost of a second placement.

## Where the floor comes from Signals in fibre travel at roughly two-thirds of the speed of light in vacuum: about **200 kilometres per millisecond**, or about 5 microseconds per kilometre. Cable does not run in straight lines — it follows coasts, land routes and existing rights of way — so a practical rule is to take the map distance and multiply by something in the range of 1.3 to 1.6 before converting. Switching and queuing on the path add more. Work an example. A user about 9,000 km from the region, with a path factor of 1.4, is about 12,600 km of fibre away. At 5 microseconds per kilometre that is roughly **63 ms one way** and **126 ms per round trip** — before a single line of your code runs. That number is a **floor**: it is the best case, and it is set entirely by where the two endpoints are. ## What multiplies it The floor is per round trip, so the thing that turns a tolerable number into a bad one is the *count* of round trips a single user action needs: - **Connection setup.** Establishing a connection and negotiating an encrypted session costs round trips of its own before any request is sent. Reusing an established connection avoids paying that again. - **Dependent calls.** If the client must receive answer A before it can ask for B, the two round trips add. Six dependent calls at 126 ms is over 750 ms of pure waiting. - **Chatty protocols.** A design that fetches a list and then one detail per item turns one user action into dozens of crossings. This is why the same backend can feel instant nearby and unusable far away while every server-side metric looks healthy. Your dashboards measure the work; the user experiences the work *plus* every crossing. ## What does and does not move the number | Change | Effect on the floor | Why | |---|---|---| | Larger machine family, faster cores | None | Shortens server work, not the path | | More instances behind the entry point | None | Adds capacity; the distance is unchanged | | Raising a service quota | None | Quotas gate how much you run, not how far away it is | | Fewer, batched or parallel round trips | Large | Fewer crossings at the same floor per crossing | | Reusing an established connection | Moderate | Avoids paying setup round trips repeatedly | | Serving users from a closer region | The only change to the floor itself | Shortens the path | ## What this means for the region choice Distance is the input a user feels on every single interaction, and it is the one input that is fixed at placement time. That gives a simple discipline when choosing: 1. Work out where the users actually are — the people using the product, not the team building it. 2. Convert that distance into a round-trip estimate and decide whether the product survives it. 3. Count the round trips a typical user action needs, since the floor is paid once per crossing. 4. If the answer is unacceptable and the work cannot be made less chatty, the region is wrong for those users. There is a second-order effect worth naming: the floor also applies between *parts* of your system. Splitting a service from the store it reads, and putting them in different regions, makes every internal query pay a cross-region round trip. That is usually far worse than the user-facing distance, because internal call counts are higher than anyone estimates. ## The honest limits of the answer Moving closer is not free and not always possible. A residency obligation may pin the workload where it is. Traffic that must reach the durable store still has to travel, so only the work that can be answered without touching it benefits from being closer to the user. And distance is the floor, not the whole latency: a badly performing service is slow everywhere, and a distant one is slow *on top of* that. Measure both before blaming either — the separator is whether the same request is fast from a client near the region.

  • Server-side timings look healthy while distant users complain. How do you confirm distance is the cause?
    Compare the same request measured at the client from near the region and from the complaining geography. If server-side duration is identical in both and only the client-observed time differs by roughly the expected round trip, the gap is the path. Then count how many crossings one user action needs, because that multiplier is usually the real problem.
  • Does moving the service closer to the users help if the store it reads stays where it is?
    Only for work that can be answered without touching the store. Anything that must read or write it now pays a cross-region round trip on the internal call instead of the external one, and internal call counts are usually higher. Splitting a service from its store across regions often makes the total worse, not better.
  • The product must serve two geographies far apart. What does that force?
    It forces a decision rather than a tuning exercise: accept a poor floor for one side, run separately placed deployments with the data question that raises, or restructure so the latency-sensitive path does not need to cross. What it is not is something you fix by resizing machines in one region.

Distance behaves like the postal system: a faster clerk at the far end does not shorten the journey. And if you send a letter that waits for a reply before you can send the next, six questions cost six journeys.

saying these in an interview costs you the question

  • Thinks a larger machine family reduces the round trip
  • Blames the network without counting the round trips
  • Assumes fibre distance equals straight-line map distance
  • Adds instances to fix a latency complaint from abroad
  • Splits a service from its store across regions to get closer