Is a "User" microservice a good idea?

Question

I'm new to microservices, and from my understanding, DDD says for microservices to be built around business domains. This means good microservices would be like AppointmentScheduler and SendNotification in the context of a meeting booking system.

In this example, both of these microservices will require access to user data to fulfil their business functions, and I'm struggling with the best way to provide it.

To me, a User seems like an object that should exist as an entity inside a microservice, but it would need to exist in most microservices as user data is required almost everywhere. This also introduces a lot of duplication.

The other option is to have a User microservice that provides CRUD operations on the user database. This can then be used by other microservices to access the user data, but the problem I have with it is it tightly couples services together to the point where we end up with a distributed monolith, that is slightly better than a monolith in itself.

Does my reasoning seem valid? How are others dealing with problem?

Answer 1

If you really need the same User object/model/record in most of your microservices, you probably don't need separate microservices at all OR they ought to be object-agnostic as far as their knowledge goes. Thusly, each microservice manages a sub-type of a User model with the data that's needed for its functionality, with a key that's used to distinguish that User. In an ideal world, that way you can perform the necessary mutations and propagate changes throughout the system through a event broker of some sort (assuming you have a event-driven architecture), otherwise, each service would have to be aware of some (or all) other services and what they're meant to do and which types of objects they expect to receive.

Keep in mind that in a true microservice environment, each microservice is expected to have its own data store which is isolated from the rest of the system, backing up my initial statement that you should dump the concept of a User entity completely.

For instance, a SendNotification microservice would only receive an object with a websocket identifier (which is passed throughout services, eventually reaching this one) and the data that's supposed to be returned to the user, and it'd just perhaps verify that the needed fields are there and push the notification to the appropriate channel by the WS identifier. It doesn't have to know which types of objects it handles at all.

Answer 2

You can do whatever feels appropriate when it comes to User service in a distributed app.

I have several services that has a concept of a User which corresponds to the User in my User/Identity service. I want to store User's First name and Last name in each service. This data originates from User service.

When I want to change the shared User data I make a request to the User service. It then does its thing. When anything changes about the User it will result in an integration event (async messaging): UserCreated, UserUpdate, UserDeleted etc. The dependant services listen to those events to know when to update their own User representation.

Generally, you just want to store data that you need and that you will own.