I'm breaking a big monolith application into microservices, the business domain revolves around users and features, I have a few features in the application (cab booking, bill payments, home cleaning, etc) and they all depend on a user existing, my planned architecture looks like this (I'm only demonstrating 3 feature microservices here but there are more):
The problem is, every feature, needs a set of user data to serve its business function, for example, the email address of the user to send cab booking confirmation, the phone number of the user for home cleaning microservice, and maybe to know if the user is verified to do bill payments, I have 4 options to get this user data in each microservice:
option 1: Using MassTransit and service bus, I can publish events when a user is created/ updated/ removed from the users microservice, each microservice will have to subscribe to those events and update its own user table with the data it needs from user. This way, each microservice will have a copy of the user data. The drawback of this solution is data duplication.
option 2: Call users microservice through a rest api/ grpc and fetch live data every time a microservice needs user data, this creates chattiness and deep coupling between other microservices and the users microservice. This will also affect the performance and latency due to the huge number of calls made.
option 3: Using MassTransit saga orchestration, a saga could kick off by sending a command to users microservice to get me the data it needs or do the necessary validations, I feel like this could also create huge load on users microservice due to the huge number of commands to handle.
option 4: Have each microservice connect to its own database + the users microservice database to have a single point of live data but it's also coupling on the scheme of users database.
What do you think is the best solution in this case, is there an option 5?