Physical Latency Floor

A stakeholder asks for a 25 ms round trip between London and New York and suggests a better network provider. Light in fibre travels at about two thirds of its vacuum speed, roughly 200,000 km per second, because of the refractive index of glass. The route is about 6,000 km once cable landing points are included, so one way is 30 ms and a round trip is about 60 ms before any equipment is involved. Measured figures on that path are 70 to 90 ms.

The useful form of the constant is about 1 ms per 100 km in each direction, so 2 ms per 100 km of round trip. From that, a few numbers worth carrying: within one metropolitan area, under 1 ms; across a continent, 60 to 80 ms; transatlantic, 70 to 90 ms; Europe to Singapore or Sydney, 160 to 300 ms.

The floor is not a performance target. It is the number that tells you whether a conversation about performance is worth having at all.

Why it matters

Latency targets are routinely negotiated as though they were procurement decisions, and the negotiation wastes quarters. A provider sells a shorter path and better peering, not a faster medium, which is why premium low-latency routes exist for trading firms: they buy distance, not speed. Knowing the floor turns a doomed optimisation programme into a design conversation in one meeting.

It also prevents the more expensive mistake in the other direction: a design with one synchronous cross-region call inside a budget that the call alone consumes. That mistake survives review because each component looks fast, and it surfaces in production when the first user outside the primary region complains.

Implementation patterns

• Compute the floor before agreeing any cross-region latency target, using 2 ms per 100 km of round trip plus 30% for real routing, and state it in the design document next to the target.
• Count round trips, not milliseconds. A cold connection costs a TCP handshake plus one more for TLS 1.3 (two for older versions), so a first request pays the floor 2 to 3 times. Connection reuse, session resumption and pooling remove multiples of the floor, which is a larger win than any server-side tuning.
• Move the data, not the compute, when the target binds: a read replica in the user's region makes the arithmetic disappear. Anything that must be authoritative and remote needs the promise changed instead.
• Acknowledge locally, reconcile asynchronously, where the business rule permits. A local write with an eventual confirmation is the standard answer to a target the floor forbids.
• Budget explicitly. Write the request path as a list of hops with their propagation cost and their processing cost, and check that the sum fits before implementing anything.

Industry example

Every published multi-region design reflects this constant rather than arguing with it. Google's Spanner paper (2012) describes synchronous cross-region replication and is explicit that commit latency includes the wide-area round trip, which is why deployments choose replica placement by geography rather than by capacity. Read-local architectures at CDN providers exist for the same reason: the only way to serve a 20 ms response to a user 6,000 km from your database is for the answer to already be near them.

The financial industry makes the constraint visible in its spending. Dedicated low-latency routes and microwave links between exchanges are bought specifically because the medium's speed is fixed and the only remaining variable is path length.

Failure scenarios

• A latency programme with no achievable target, which burns a quarter and ends in a renegotiation that could have happened on day one.
• A synchronous permissions or consistency check to the home region, cheap in the primary region and fatal everywhere else, so p99 is a function of user geography and looks like a mystery.
• Chatty protocols over long paths, where 8 sequential round trips turn an 80 ms floor into a 640 ms page.
• A cache that does not help, because the request must be authoritative; teams add a CDN and observe no improvement.
• Synchronous cross-region commits accepted without pricing the write path, so every write pays the floor and throughput falls with distance.

Trade-offs

When not to use it

Do not reach for the floor before checking your own stack. Most missed latency targets are a 200 ms query, a cold cache or a serial fan-out, and invoking physics to explain those costs credibility that is hard to recover. The floor is the right tool when the two endpoints are fixed and far apart and the work genuinely must happen at the far end. It is also irrelevant for throughput questions: bandwidth and latency are independent, and a design that is slow because it transfers 40 MB is not constrained by propagation at all.

Interview question

Q: Product wants a 30 ms p99 for European users on a service whose database is in Virginia. Tell me whether that is possible, and what you would propose.

What a strong answer covers: computing the floor from distance and the speed of light in fibre, so the transatlantic round trip is named as 70 to 90 ms and the target is impossible for a remote-authoritative read; distinguishing reads from writes; proposing a European read replica or a cache with a stated staleness, or a local acknowledgement with asynchronous reconciliation; counting round trips, including the handshake cost on a cold connection; and reframing the requirement as what the user must see in 30 ms rather than what the system must do.

Quick check

Quiz: What round-trip cost should you assume per 1,000 km of fibre? About 20 ms, from roughly 10 ms of propagation each way, before equipment and processing.

Flashcard: Why can no provider deliver a 25 ms London to New York round trip? — Propagation in glass fixes one way at about 30 ms over that distance, so 60 ms is the floor; a premium route buys a shorter path, not a faster medium.