The Sanctity of the Single Hop
There is a quiet, almost theological certainty in a single network hop. It’s a concept so simple it borders on the profound, a direct, unmediated connection between two points. In our architectural diagrams, we celebrate sprawling meshes, redundant paths, and cloud-native fabrics that weave services together into resilient, scalable tapestries. We draw arrows that arc gracefully between availability zones and continents, proud of the complex dance we’ve orchestrated. But in the silent, dimly lit heart of a truly reliable service, I find myself yearning for the opposite. I find sanctity in the single hop.
This isn't about raw performance, though the lack of latency is a welcome side effect. It’s about the reduction of metaphysical complexity. Every hop, every additional router, switch, or load balancer introduces not just another point of potential failure, but another consciousness into the conversation. Each device has its own state, its own routing table, its own idea of what ‘up’ and ‘down’ mean at any given nanosecond. A packet traveling across a continent is subjected to a thousand tiny judgements, a series of hand-offs between independent agents who know nothing of its ultimate purpose. It’s a message passed through a crowd.
But a single hop is a private audience. It’s two machines on the same switch, or a server talking directly to its dedicated backup appliance. The connection is immediate, the path predetermined and unwavering. There is no debate, no alternative route to consider. The packet leaves one interface and is received by another with a minimum of ceremony. In this space, the logic of the application is the only logic that matters. The network becomes a given, a constant, like gravity. We can stop worrying about its whims and focus on the work.
The Shadow of a Doubt
This simplicity is, of course, a form of luxury. To architect for the single hop is to make a deliberate choice to keep things close, to prioritize certainty over scale. It’s the decision to run a logger on the same host as the application, accepting the I/O burden in exchange for the ironclad guarantee that the log message will be written, regardless of the wider network’s health. It’s the local, scripted backup that runs at 2 AM, its data traversing a dedicated crossover cable to a NAS unit sitting two rack units below, a ritual undisturbed by internet BGP flaps or DNS hiccups.
In these arrangements, failure becomes starkly legible. When a service that depends on a single hop goes quiet, the investigation is brutally straightforward. The problem is either here, or it is there. There are no shadowy intermediaries to blame, no need to pore over traceroutes looking for the guilty party. The clarity is almost restorative. It forces a direct confrontation with the integrity of your own systems, stripping away the convenient obscurity of a complex network.
We build these grand, distributed cathedrals of microservices, and they are marvels of engineering. But I wonder if we sometimes forget the humble chapel—the small, self-contained service that asks for nothing from the world except a power cord and a single, faithful network connection to its one true counterpart. In that minimalism, there is a kind of peace. It’s the quiet hum of a process that knows exactly where it’s going, and has only one, simple step to get there.
Notes & further reading
A few pages I came back to while writing this: