Had a query about MIcroservice granularity. Will try to explain my query with an example.
Assume I have above 3 tables in database, with Many to one relationship between Person -> NativeCountry table. One to Many relationship between person -> LanguagesSpoken in database.
Front end Application is suppose do CRUD operation on person entity and will also have capability to retrieve people based on nativecountry or spokenlanguage.
Does it makes sense to develop 3 independent microservices for each of the entities and then use Aggregator Microservice at upper layer to build combined data for UX layer or I should think of combining those to build just single microservice?
From your description of the problem, it sounds like "people" are at the center of the functionality and the use case of the service if I understand this correctly.
Since the three required features are around people and one feature requiring just listing the languages, I would argue that this should be one microservice (again without knowing if there are external services that depends on the other possible entity services). My argument here would be that in order to serve requests, people is the entity of interest with the native country and language being just a dimension to retrieve users.
If you break each of the entities, people, language, and country into different microservices, the services would be too small and the complexity would increase eg. you might need to make multiple requests to multiple services to generate a single response while there may not be a need to. As for the one last feature that doesn't quite revolve around people, I would say that its too small of a feature to be in a microservice. Until there becomes a need for the last feature to be a standalone service, I would advise for putting this into the "people" microservice.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With