Speed of Light Is a Floor
Speed of Light Is a Floor is the irreducible lower bound on network latency caused by physical distance: bits are carried by electromagnetic signals, and those signals cannot outrun light. Bandwidth, faster servers, better kernels, and cleaner code can remove other delays, but they cannot make a round trip take less time than propagation permits.
This matters because engineers often reason about remote calls as if latency were mostly a software or capacity problem. For nearby systems that can be good enough, but across regions the wire distance dominates surprisingly quickly. If a request must cross an ocean, every synchronous dependency, database commit, handshake, retry, or quorum message inherits a minimum wait before any application work can even begin.
The calculation is simple: take the path distance, divide by signal speed for a one-way trip, then double it for a round trip. Light in vacuum is the absolute limit, but fibre is slower, around two thirds of that speed. Real cables also do not follow perfect great-circle routes, so production paths usually have stretch before router processing, queues, packet loss, and retransmission add anything.
The trade-off is that you cannot buy your way below this bound. You can shorten the path by moving compute, data, or replicas closer to users. You can reduce protocol round trips, avoid synchronous cross-region calls, cache, pipeline, or make operations asynchronous. But if correctness requires a response from a distant region, the distance cost remains part of the critical path.
Engineers meet this when choosing cloud regions, setting latency SLOs, designing multi-region databases, debugging slow handshakes, or explaining why a high-bandwidth private link is still not low-latency. It is commonly misunderstood as a networking quality issue. Sometimes it is, but the honest answer starts with distance: compute the propagation floor first, then investigate routing and congestion above it.
Common questions
- How do I estimate the best possible round-trip time from distance?
- Use distance divided by propagation speed for one direction, then double it. Vacuum gives the theoretical lower bound; fibre gives a more realistic floor. After that, add realism: cable routes are longer than straight lines, and routers, queues, retransmits, and protocol handshakes sit on top of the propagation delay.
- Does more bandwidth reduce the speed-of-light floor?
- No. Bandwidth changes how much data can be in flight per unit time; it does not change how fast the first bit reaches the other side. A larger pipe helps bulk transfer and congestion, but a small request that must traverse a long distance still waits for propagation before a reply can return.
- Can protocols like QUIC or newer TLS remove this latency?
- They can reduce how many round trips are needed before useful data flows, which is valuable on long paths. They do not make any individual round trip faster than physics allows. The gain comes from avoiding extra waits, resuming sessions, or sending data earlier, not from beating propagation speed.
- What should I do if a dependency is too far away?
- First decide whether the dependency must be synchronous. If not, queue, replicate, cache, or make the operation asynchronous. If it must be synchronous, move the caller, callee, or required data closer together. For consensus or database commits, be explicit that replica placement directly sets part of the write latency.