Understanding client service discovery mechanism

Question

I'm trying to understand how to implement service discovery pattern in my architechture. I understand that each instance of one service must register itself in the service registry when starts and then refresh the registration each, for instance, 30 seconds.

Say I have a purchases service that needs to read some data from clients service. Both are REST based services.

Do I need to query the clients service's URL in the service registry each time it needs to make a request against it? Doesn't it have performance consequences?

Answer 1

Doesn't it have performance consequences?

Yes, but how much ? e.g. how often are you querying the service (and the registry). And how much interaction with the service is going on. e.g. are you querying the registry once and then conducting a complex interaction with the service. If your registry service is lightweight (and I can't imagine it wouldn't be) then I wouldn't worry too much about it.

If it does become a problem, why not implement an exception-based mechanism. e.g. query the registry once, and then use that until you encounter an error, in which case you go back to the registry to find a new service.

There are a variety of solutions to this problem. One possible solution not using a registry is to let each service broadcast its location (via IP broadcast or multicast). Each client can listen to this and maintain a set of known services (timing out entries as they disappear). That's perhaps more complex to implement, but avoids the single-point-of-failure that you may introduce with a sole registry.