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?

  • 1
    A distributed monolith is not really better than a monolith, usually even harder to maintain. It's a term used to describe a failed transition to a microservice architecture. Sep 10, 2019 at 14:35
  • 1
    Aren't you confused with authentication and user data ? Sep 10, 2019 at 14:36
  • I think it would help you to list what user data these services need. To start, what user information does a notification service require?
    – JimmyJames
    Sep 10, 2019 at 14:45
  • 3
    Assuming you have all the answers will not help you get any. The point of the exercise is to get you to realize you probably don't need user data in every service. A really clean, reusable microservice will not need 'user data'. It needs a destination for the notifications.
    – JimmyJames
    Sep 10, 2019 at 15:07
  • 2
    @Umair A good way to find out if you can do this or that with microservices is to determine why you need microservices in the first place. Unless you're trying to solve a specific problem in which they are the superior option, using microservices just for the sake of it is usually a terrible idea that will bite you in the butt like a rabid handmade html-regex parser. Just sayin'.
    – T. Sar
    Sep 10, 2019 at 16:13

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.