3
  • Person
  • NativeCountry
  • SpokenLanguages

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?

Pras Tiwari
  • 35
  • 6
  • While this question is valid, its a little difficult to answer without understanding the business domain. Generally, use a single microservice if the query is to have Person, NativeCountry, and SpokenLanguages queried together and never separately and separate microservices if there's a larger domain that requires them to be independent. If you can add some more domain specific details and how some other service may use them, it might give a little insight for a more accurate answer. – Will C Apr 28 '16 at 14:12
  • Lets say on the UI there will be facility to add new person which will obiviously have nativecountry and languages spoken attached to it. However for pre-populating available spoken languages on create person UI, there may be need to query available languages in DB and populate. On UI there should also be a search section where it's possible to provide nativecountry or one of the language spoken as search criteria, to be able to search people matching this. – Pras Tiwari Apr 28 '16 at 22:35
  • 1
    The database server itself is one big service. You wrap or break it into separate services only is their existence is any good. – S.D. Apr 29 '16 at 19:11
  • 1
    If you have foreign keys between tables, the services technically would not be microservices any longer because there is coupling on the database level. The idea is for the services to have their own/independent storage. – Dmitry S. May 02 '16 at 04:24

1 Answers1

3

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.

  • Search for people by native country
  • Search for people by language
  • Add a person with both their native country and the languages spoken
  • List all the languages

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.

Will C
  • 1,750
  • 10
  • 20