Cloud physics rules out sub‑10ms

Distance is the story here. Not CPUs, not Kubernetes, not how fast your code runs once it gets there. If a control loop has to leave a machine, cross a metro, hit a cloud region, and come back inside 10 ms, physics starts saying no before software even gets a vote. That’s why the argument Harshil Tomar and VLink were having this week matters — they were really arguing about where latency-sensitive systems can physically live. ### What does “sub‑10 ms” actually mean? It means the whole loop — send, compute, respond, act — has to finish in under 10 milliseconds. Not just the server-side processing. The full round trip matters. In trading, robotics, industrial control, and some inference workloads, that budget disappears fast because network travel time is part of the loop, not an implementation detail. ### Why does physics kill the dream first? Light in fiber does not move at vacuum speed. A good rule of thumb is about 200,000 km/s, which means roughly 5 microseconds per kilometer one way. So a 4,000 km path is about 20 ms one way, or 40 ms round trip, in theory. That is the clean-room minimum before detours, routers, serialization, congestion, or retransmits. A research paper on U.S. fiber latency notes that real internet paths are often far slower than the speed-of-light lower bound because routes are not geographically shortest. (bdebopam.github.io) ### So is this just a coast-to-coast problem? No — it shows up much earlier. The internet usually does not take the straightest path, and shared networks add queueing and jitter. That means even if your cloud region looks “nearby” on a map, the effective path can still break a tight control budget. The catch is determinism. A median of 8 ms is useless if the 99th percentile jumps to 25 ms right when markets gap or a machine needs a response now. (bdebopam.github.io) ### Why do trading people care so much? Because financial markets already organize themselves around geography. The main U.S. equities venues cluster in New Jersey — Mahwah, Carteret, and Secaucus — precisely so firms can shave transmission time down to microseconds and low single-digit milliseconds. Traders Magazine’s market-structure breakdown shows those venue-to-venu(bdebopam.github.io)-low-latency wireless links between those hubs for the same reason. (tradersmagazine.com) ### Doesn’t cloud still help during volatility? Yes — and this is where VLink’s point lands. Cloud is great when the problem is elastic capacity. If volatility spikes and you suddenly need more risk calculations, more simulation, more ingestion, more logging, or more parallel analytics, cloud can scale faster than a fixed colo footprint. T(tradersmagazine.com)loser to Oregon. ### Why can’t you just optimize harder? Because latency has layers, and only some are software problems. You can trim serialization, use better protocols, pin threads, and keep hot data in memory. All good. But once wire time dominates, optimization buys basis points, not miracles. It’s like tuning a race car when the actual issue is that the track is 3,000 miles long. ### What architecture falls out of this? A split one. Put the hot path — execution, control, immediate decisioning — on-prem or in colo, as close to the venue, device, or actuator as possible. Put the elastic and less timing-sensitive work in cloud — analytics, model training, historical replay, dashboards, batch risk, and overflow compute. That is not anti-cloud. It is just admitting that bandwidth is rentable, but proximity is not. ### Bottom line? Cloud is a great amplifier, but a bad substitute for locality. If your loop really needs sub‑10 ms end to end, the first design decision is not software stack — it’s geography.