11.6.1: Name Services in Distributed Systems

One of the simplest and most ubiquitous name services is DNS (Domain Name System) – it translates domain names to IP addresses globally. In cloud applications, DNS is often used for service discovery (e.g., your microservice might look up db.prod.internal to find the database’s IP). Cloud providers offer internal DNS for VM hostnames and often service registries for container orchestrations (like Kubernetes has its own DNS for services). The principle is to decouple the name of a service from its dynamic location, which can change due to scaling or failures. Service discovery systems (like Netflix Eureka, HashiCorp Consul, or AWS Cloud Map) extend this by allowing services to register themselves and clients to query a service name to get a current endpoint (often providing health-checking and load-balancing info too).

For example, in a microservices architecture on AWS, you might use AWS Cloud Map or simply AWS’s internal DNS naming for ECS/EKS tasks such that one service can find another via a consistent name. Kubernetes employs a cluster DNS so that if you have a service named inventory in namespace prod, other pods can resolve inventory.prod.svc.cluster.local to reach it. This level of indirection is crucial in cloud environments where instances are ephemeral and IPs are not fixed.

Another example is Zookeeper or etcd acting as a naming and coordination service. Systems like Apache Kafka use Zookeeper to keep track of which broker is leader for which partition – effectively, Zookeeper serves as a metadata store mapping partition IDs (names) to broker addresses. Applications might use Zookeeper for their own naming (you can create znodes that act like directories of services).

Name services must be highly available and consistent enough that components can reliably connect. Typically, these services themselves are replicated and use consensus (etcd, Zookeeper use Raft/Paxos under the hood) to maintain a consistent view of the name->address mappings.

---