Reputation: 171
There are lots of articles discussing the importance of maintaining a central registry in a system based on microservices, with different strategies for registering and perform discovery. However, all the articles are centered around discovering other microservices.
When a microservice requires access to a resource available on the network (ex. a database), should the service retrieve the database location from the registry?
If yes, in the database example only the client discovery pattern makes sense to me, because it's necessary to create a connection pool.
Any thoughts about this?
EDIT: In the example above, the database is part of the microservice.
Upvotes: 1
Views: 242
Reputation: 581
If possible, the microservice should not be reliant on any external resource, meaning the database should be inside the same service. However, if you for some reason must have your database as an external resource, and you cannot give a connection string directly to it. I guess you would use the client discovery pattern, but then I feel it isn't microservices anymore as they would not really be self-contained.
In my opinion you should keep your microservices self-contained. They should not depend on a "database"-service, but rather if there is information available to a service available on the message bus, it can take action. If that information originates from the database or not is not relevant for the sake of that service. But that requires some sort of message queue.
If you have to rely on http requests or other non-centralized communication I agree, the client discovery pattern seems suitable.
Upvotes: 2