To make this discovery service pattern successful, the main ingredient is to keep data in this discovery service updated. Any new service coming into existence or one that is destroyed or pulled out for maintenance should be aware of every event happening with its client. The following are the two types of registering mechanism:

• Self-registration
• Third-party registration

In self-registration, each microservice coming up in the system should register itself to the discovery service. While shutting down, it should also notify the discovery service. With these, the notification discovery service marks services as available or not available. Self-registry looks like a simple and clean solution for this, but it contradicts the single responsibility principle. Microservice will have one more responsibility of notifying the discovery service about its events.

The following diagram explain a method of self registry. In this, Service B is looking for the Service A instance and sending a request to the discovery service. When Service A comes up, it register itself. After that, service discovery is sharing the status and meta data of Service A with Service B when available:

In third-party registration, a separate process along with service discovery is responsible for keeping an eye on all the microservices running. This new process uses different mechanism to check the healthiness of the microservice such as poll, heartbeat, or hitting microservice health URL, and updates information in it. It should have some mechanism in place to detect the failing of any microservice.