Latency is geography

Light in a vacuum covers 300 kilometers in a millisecond. In glass, with a refractive index around 1.47, it manages roughly 200. That single number decides more about a real-time data product than any software choice made on top of it, and it is the reason we describe placement before we describe pipelines.

Work through a familiar pair. London to New York is about 5,570 kilometers in a straight line, which is roughly 28 milliseconds of glass one way if the cable were laid along the great circle and nothing in between did any thinking. Cables are not laid that way, and the equipment along the path is not free, so a real one-way figure is closer to the mid-thirties and a round trip lands near 70 milliseconds on a good day. No optimization recovers that. It is the transatlantic tax, payable per crossing, and the only way to stop paying it is to stop crossing.

Now place a conventional collection architecture on that map. Collectors sit in a handful of cloud regions, which means a source in Taipei and a source in Santiago both reach a machine that is a continent away, and the resulting record then travels back out to a client that is frequently a different continent away again. The compute in the middle is measured in milliseconds and gets all the engineering attention; the two long hauls bracketing it are measured in tens of milliseconds each and get a diagram. This is why edge computing is not a fashion in this industry - the dominant terms in the budget are both distances.

The consequence is that latency work has an unusual shape. There is a large one-off gain available from moving the machinery, and a long series of small gains available from optimizing the code, and teams reliably spend their effort on the second because it is the one that fits in a sprint. Shortening the first hop by putting an edge node near where events surface and the last hop by serving from the point of presence nearest the client is a capital and operations problem rather than a software problem, which is exactly why it is defensible: a competitor can copy a parser in a week.

Distance is not the only term, and it would be dishonest to imply otherwise. Every network boundary a packet crosses adds queueing and a routing decision, so a path that transits four autonomous systems is slower than its kilometers suggest - which is an argument for carrying traffic inside one network for as much of the journey as possible. Protocol behavior matters too: each handshake costs at least one round trip, so a design that opens a connection per request pays the geography repeatedly while a long-lived stream pays it once.

And geography cannot rescue a source that publishes on a schedule. If an event only becomes available in a file produced four times a day, a node ten kilometers away learns about it at the same moment as one ten thousand kilometers away. That is a different constraint with a different fix, and conflating the two is how latency claims become unfalsifiable. Placement bounds how fast you can be once something is available; the source's own cadence bounds when it becomes available at all, which is the half-interval tax rather than a distance problem.

For a buyer, the useful question is a map question rather than a performance question: where does your listening happen relative to where my events occur, and where does delivery happen relative to where my systems run? A vendor that answers with a benchmark has answered about the small term. One that answers with a topology, and stamps the serving node on every record so you can verify it, has answered about the two that dominate. The tail is where the difference shows up first, because a long path has more places to wait.

The arithmetic is also a tool rather than an argument, and it takes an hour to run for yourself. Write down where your systems actually execute, take the great-circle distance to the regions your events occur in, divide by 200 kilometers per millisecond, and double it for a round trip. That number is your floor. Everything a vendor quotes below it involves either a shorter path than the one you assumed or a definition of latency that starts later than yours - and both are worth asking about, because one of them is architecture and the other is measurement.

None of this is exotic. It is the same arithmetic that made delivery networks a category thirty years ago, applied to the opposite direction of travel: not pushing files out to the edge, but hearing the world at it.