Overview
In a microservices architecture, invoking another service's functionality requires knowing the IP addresses of the service's instances. However, these addresses cannot typically be hardcoded because they are assigned dynamically. Additionally, failures, updates, scaling events, and other situations can change the location of service instances. The Service Registry pattern solves this problem.
Problem
In a microservices architecture, invocations between services cannot be made statically, because the IP addresses of service instances are dynamically assigned. Furthermore, failures, updates, scaling mechanisms, and other situations can cause service instance locations to change. How can a service discover the current network location of another service?
Solution
A Service Registry is a service for registering services that contains a database of services — their instances and respective locations — which must be updated every time a service in the architecture starts or stops. Client applications, routing services, or others make a request by service name to the Service Registry to obtain the locations of the available instances of a given service.
Health Check API
Each service in the architecture should implement a health check API — a method that allows the Service Registry to determine whether the service is ready to receive and process requests, access its database, and perform other checks. This ensures the Service Registry only returns locations for healthy, available instances.
Technologies
Deployment platforms such as Docker and Kubernetes implement the Service Registry, Server-side Discovery, and request routing using the 3rd Party Registration approach — meaning the platform handles all of this automatically, removing that responsibility from the developer.
Trade-offs
Benefits
- Enables dynamic service discovery — services can be located even when their IPs change
- Supports scaling, failover, and updates without reconfiguring consumers
- Centralised knowledge of available service instances
Drawbacks
- Additional component to develop, deploy, and maintain
- Must be highly available — if the registry is down, service discovery fails
- Registry data must be kept up to date as services start and stop
When to Use
Apply Service Registry when:
- Service instances are dynamically assigned addresses (containers, cloud environments)
- Services scale horizontally and the number of instances changes at runtime
- You are not using a deployment platform that provides this out of the box
Not needed when:
- Using Kubernetes or a similar platform — it already provides service registry, discovery, and routing, removing this responsibility from developers