Service Registry

A Service Registry is the authoritative store of where service instances currently live. In a dynamic environment, instances come and go constantly: autoscaling adds and removes them, deployments replace them, and failures kill them. Their IP addresses and ports are not stable, so consumers cannot rely on hard-coded locations. The registry is the source of truth that answers "where is service X right now?".

How It Works

Each service instance is registered with the registry, recording its service name, network address, and metadata such as version or zone. Registration happens either by the instance itself (self-registration) or by a third party such as an orchestrator (third-party registration). The registry continuously verifies liveness through health checks or heartbeats and removes instances that stop responding, so stale entries do not linger.

Consumers and load balancers query the registry to obtain a current list of healthy instances. Common implementations include Consul, etcd, ZooKeeper, and Netflix Eureka. Kubernetes provides an equivalent through its built-in endpoints and DNS, backed by etcd.

Registries usually expose both an HTTP API and DNS interface so clients can query in whichever way suits them. Entries carry a time-to-live, and instances must re-register or heartbeat before it expires. Many registries also support tags and key-value metadata, enabling consumers to filter instances by version, datacenter, or capability when selecting a target.

When to Use It

Use a service registry whenever instance locations are dynamic: container platforms, autoscaling groups, and any system where addresses are assigned at runtime. It is the foundation that service discovery is built on.

If you run a fixed set of services at known addresses, a static configuration file or DNS record may suffice and a registry adds little.

It is also worth adopting when you need richer routing decisions than DNS alone can express, such as preferring same-zone instances to reduce cross-zone traffic or routing only to instances advertising a compatible API version.

Trade-offs

The registry is critical infrastructure and a potential single point of failure, so it must be clustered and highly available, usually with a consensus protocol such as Raft. This adds operational complexity. There is also a freshness window: between an instance failing and the registry detecting it, consumers may be handed a dead address, so clients still need retries and timeouts. Health-check tuning is a balance between fast failure detection and false positives. In practice teams treat the registry like any other tier-zero dependency, running an odd-sized cluster across failure domains and alerting on quorum loss before it can affect discovery.

Related Patterns

Service Discovery uses the registry to locate instances. Self-Registration and third-party registration are the two ways entries get created. Health-check mechanisms keep the registry accurate. Client-side and server-side discovery describe who consults the registry.

Example

An order service scales from 3 to 12 instances under load. Each new instance registers with Consul on startup, advertising its address and a /health endpoint. Consul polls that endpoint every few seconds. When traffic falls and 9 instances are terminated, Consul removes them within its health-check window. The payment service, which calls orders, asks Consul for healthy instances and load-balances across whatever set currently exists.