Service Registry

What is a service registry?

A service registry is the central database at the heart of service discovery: a live, continuously-updated directory that maps logical service names (“payment-service”) to the actual network locations of their current healthy instances. In a dynamic environment — Kubernetes, microservices, autoscaling fleets — instances constantly appear, move, and disappear, so their addresses can’t be hardcoded. The service registry is the source of truth that answers “where is a healthy instance of service X right now?”, and everything else about service discovery is built around keeping it accurate and querying it.

How it stays current — registration and health checking

A registry is only useful if it reflects reality, so two mechanisms keep it fresh. Registration: instances add themselves (self-registration, on startup) or are added by the platform (third-party registration — how Kubernetes does it, with the control plane tracking pods automatically). Health checking / deregistration: the registry must promptly remove instances that have died or become unhealthy, or callers will be routed to dead endpoints. This is done via health checks (the registry or an agent pings instances) and often heartbeats with leases — an instance must periodically renew its registration or the registry expires it, so a crashed instance that can’t send heartbeats is automatically evicted. Getting this right is the whole game: a registry that’s slow to drop dead instances sends traffic into the void, and one that’s too aggressive evicts healthy-but-briefly-slow instances. Consumers then either query the registry directly (client-side discovery) or reach it through a load balancer/router (server-side discovery). Common implementations include Consul, etcd, Eureka, and Zookeeper; Kubernetes and cloud platforms provide registries built in, which is why many teams use one without ever naming it.

The critical-infrastructure caveat

The thing to internalize is that the service registry is critical infrastructure and a potential single point of failure. Because inter-service communication depends on the registry to locate targets, if the registry becomes unavailable, services can’t find each other and the whole distributed system can seize up — a registry outage can cascade into a system-wide outage. This forces two design requirements. First, the registry itself must be highly available and consistent, which is why production registries are run as distributed, replicated clusters (etcd and Consul use consensus protocols like Raft to stay consistent across nodes) rather than a single instance. Second, clients should degrade gracefully — caching last-known-good locations so a brief registry hiccup doesn’t immediately break all calls, while balancing that against the risk of using stale entries. There’s an inherent tension here between consistency (always-accurate registry data, which favors strong-consistency systems like etcd/Consul) and availability (staying usable during partitions, which Eureka deliberately favors, tolerating some staleness to keep serving). The recurring mistakes: treating the registry as an afterthought rather than the load-bearing component it is, running it non-redundantly, and having no client-side fallback when it’s briefly unreachable.

What people get wrong

• Running it non-redundantly — the registry is a single point of failure for all service-to-service calls; it must be a replicated, highly-available cluster.
• Weak health checking/heartbeats: if dead instances aren’t evicted promptly, callers get routed to endpoints that no longer exist.
• No client-side caching fallback — without last-known-good caching, a momentary registry outage instantly breaks every lookup and can cascade system-wide.

Primary source: Consul: Service Discovery