Say there is a magic show that is going to take place inside an auditorium. This show is open to everyone, and anyone can come to the auditorium to attend it. At the gate of the auditorium, there is a registration desk where you need to register before you can enter the auditorium. As soon as the audience members start coming, they first go to the registration desk, provide their information—such as their names, addresses, and so on—and are then given a ticket to enter the auditorium.

The service registry is something like this. It is a special kind of database that keeps a record of which services are running on an infrastructure and where they are located. Whenever a new service comes up, it registers itself with the service registry, identifying itself.

The service registry also acts as a lookup point for these services. For example, if Service A wants to communicate with Service B, then Service A makes a call to the service registry, asking for the network location of Service B. If Service B was registered with the service registry, then the service registry looks up the network address of Service B inside its internal database and sends it back to Service A. After this, Service A can make calls to Service B.

But what happens if Service B went down because of some issue? The service registry is responsible for keeping its service database updated through multiple mechanisms. One of the simplest mechanisms to implement is the use of heartbeats. Here, any service that is registered to the service registry sends periodic heartbeats to the service registry to mark itself as alive. If Service B goes down, these heartbeats will cease to exist, prompting the service registry to remove the entry for Service B from its database.

So, this is how a service registry functions. Now that we know about the service registry, we are ready to explore the patterns of service discovery.