The Anchor and the Buoy: Two Philosophies of Service Discovery

In the quiet, humming world of our small services, a fundamental question persists: how do they find each other? The answer isn't just technical; it's almost philosophical, revealing our core beliefs about stability and change. Two contrasting approaches have emerged in our own small-scale deployments, each with its own virtues and costs. We call them the Anchor and the Buoy.

The Anchor is the old way, the reliable way. It is the static IP address, the entry in a venerable /etc/hosts file, the hard-coded DNS name that hasn't changed in half a decade. An Anchor-based service knows its dependencies with absolute certainty. There is no negotiation, no runtime query. It is a system built on cartography, trusting that the map drawn at deployment will remain accurate for the entire journey. Its logs are clean and simple; a connection error means the other service is genuinely down, not lost. The Anchor provides a profound kind of stability, the comfort of a known and fixed point in a shifting digital sea.

Its counterpart, the Buoy, is the dynamic modern way. It is the service registry, the consul agent, the Kubernetes endpoint. A Buoy-based service asks "where are you?" each time it needs to make a connection. It embraces ephemerality, designed for a world where IPs are leased, containers are cattle, and everything is potentially transient. The Buoy is fluid, allowing for seamless scaling, rolling updates, and graceful handling of individual instance failure. It represents a system built on navigation, trusting the buoys and lighthouses to guide it to its target, regardless of how much the coastline has changed since it last set sail.

The Trade in Trust

Choosing between them is a trade in trust. With the Anchor, you trust your initial configuration absolutely, but you must also trust that nothing will ever invalidate it. A changed IP or a retired hostname becomes a silent, catastrophic failure. The Anchor demands rigorous, upfront planning and a certain rigidity. The Buoy, meanwhile, trusts the discovery process implicitly. Your faith is placed in the health checks and the registry itself. But this introduces a new critical path: if the Buoy system falters, every service becomes blind and adrift, a single point of failure that can sink the entire fleet.

We run both. The core database, the immutable ledger of our operation, is an Anchor. Its address is etched into stone. It never moves, and everything knows exactly where to find it. The myriad of microservices that process data, however, are Buoys. They come and go, scale up and down, and the registry keeps traffic flowing to them smoothly. This hybrid approach acknowledges a simple truth: not all services are created equal. Some are landmarks; others are passengers. The art is in knowing which is which, and applying the right philosophy to each, building a system that is both reliably grounded and gracefully agile.

Notes & further reading

A few pages I came back to while writing this: