A product manager asks for a 25 ms round-trip response time for users in London talking to a service in New York, arguing that a faster network provider would deliver it. Roughly what is the physical floor, and what does the answer let you do?

The assumptions, stated

Light in a fibre travels at about two thirds of its speed in a vacuum, roughly 200,000 km per second, because of the refractive index of glass. London to New York is about 5,600 km in a straight line, and real fibre routes are longer — call it 6,000 km with the cable landing points.

The arithmetic

6,000 km / 200,000 km per second = 0.03 seconds, or 30 ms one way. A round trip is about 60 ms, before any equipment.

Then add what the request actually does: a handful of router hops at a fraction of a millisecond each, a TLS handshake if the connection is new (one extra round trip with TLS 1.3, two with older versions), and the server's own work. A realistic measured London to New York round trip is 70 to 90 ms, which is why that is what you see on any public latency chart.

The number, with its range

The floor is about 60 ms and the practical figure is 70 to 90 ms. 25 ms is not achievable at any price, by any provider, without changing the geography. It is not a procurement question, and this is the kind of claim that is worth being certain about: the speed of light is a constraint and a vendor is not.

Which assumption dominates the error

Route length, by a wide margin. Fibre does not go in straight lines: it follows cable routes, and a poorly-chosen path can add 30% to the distance. This is why premium low-latency routes exist and why they are sold to trading firms — they buy a shorter path, not a faster medium. The remaining variance is in the endpoints, where a new connection, a cold cache or a busy server dwarfs the network.

What the number rules in and out

• It rules out any synchronous cross-Atlantic call inside a 25 ms budget, including a "quick" consistency check or a permissions lookup. One such hop consumes the whole budget three times over.
• It rules in the designs that actually deliver the experience: serve the read from a replica in Europe; write asynchronously; or if the write must be acknowledged transatlantically, change the promise made to the user rather than the network.
• It reframes the conversation. The useful question is not "can we get to 25 ms" but "what must the user see within 25 ms, and does that thing have to come from New York?" Usually it does not: the acknowledgement can be local and the truth can catch up.

When this is the wrong answer

The floor only binds when the data genuinely lives on the far side. If the 25 ms target is for a read, move the data and the arithmetic disappears, which is why replicas and CDNs exist. And do not deploy the argument too widely: teams sometimes invoke physics to dismiss a latency target that is really failing on a 200 ms database query, and the credibility cost of being wrong about that is high. Check the floor first, then check your own stack, and choose which conversation to have.

Common weak answers

• "We need a better network provider." The medium is glass for everyone. A provider sells you a shorter route and better peering, worth perhaps 10 ms on this path.
• "Add a CDN." A CDN helps if the response can be cached or terminated at the edge. It does nothing for a request that must reach New York to be answered.
• "It depends on the load." It does, above the floor. Below the floor nothing depends on anything, which is exactly why this arithmetic is worth doing in front of the stakeholder.