The Anchor and the Buoy: On Two Approaches to Service Discovery
In the quiet, humming world of small services, one of the most fundamental questions is also one of the most easily overlooked: how do they find each other? The answer isn't merely technical; it's philosophical. It reveals a deep-seated belief about the nature of the systems we build and the kind of reliability we value. Two contrasting approaches have emerged, each with its own virtues and its own quiet costs.
The first is the Anchor: the static configuration. This is the method of the meticulous cartographer. Before a vessel sets sail, its course is plotted. Every service knows its dependencies by their fixed, unchanging coordinates—a hostname, an IP address, a port number—hard-coded into a configuration file or etched into an environment variable. It is a system of profound certainty. There is no runtime negotiation, no third-party to query. The service knows its world with the same certainty that a lighthouse knows its rock.
This approach offers a stark, beautiful simplicity. Its operational footprint is nearly invisible; there is no discovery service to monitor, no consensus protocol to maintain. In a moment of crisis, when the network itself feels untrustworthy, the anchor holds fast. You know exactly who is talking to whom because you yourself drew the map. But this certainty is also its rigidity. To change a service's location is to redraw the map for every service that depends on it. Scaling becomes a manual act of cartography, a process of careful, deliberate updates rather than a fluid, organic growth.
The second approach is the Buoy: the dynamic service discovery. This is the method of the harbor master. Services announce their presence to a central registry—a consul, a simple etcd cluster, a nameserver—and they query this registry to find their peers. Locations are not fixed points but shifting signals, picked up from the ether when needed. The system is fluid, adaptable, and self-organizing. It embraces the ephemeral nature of modern deployments, where instances flicker in and out of existence.
The buoy grants immense flexibility. Scaling is automated; new instances simply register and are found. Failover can be nearly seamless. But this dynamism comes with a hidden tax of vigilance. You have introduced a new, critical service: the registry itself. It must be clustered for reliability, monitored for health, and secured against failure. The system's knowledge of itself is now contingent upon this central nervous system. If it falters, the entire network can lose its way, adrift in a sea of unknown endpoints.
Neither approach is inherently superior. The choice between them is a choice between two kinds of reliability. The Anchor offers the reliability of a known, immutable state, demanding upfront and ongoing manual stewardship. The Buoy offers the reliability of automated adaptation, demanding a more complex, but highly available, infrastructure. One finds stability in stillness, the other in flow. The wise builder understands that the choice is not about which tool is better, but which kind of quiet, boring reliability their particular service truly needs.
Notes & further reading
A few pages I came back to while writing this: