3

I have User, Payment, Product, Checkout services. User means for payment; payer , Product; seller, Checkout: buyer etc. When new user registered. I publish event which contains user. And Store user data for all services. That means 15000 user is X4 = 60.000 user data for all services.

Is that Ok ?

Or what should I do ?

eren arslan
  • 197
  • 2
  • 11

2 Answers2

4

Is that Ok ?

The duplication of required data itself is totally okay from my point-of-view in a Microservices architecture if it happens for the right reasons. And I even would not necessarily consider this as a normal data duplication in the first place.

Each Microservice has it's own domain model and thus the User model - which you already name differently in the different services (payer, seller, etc.) - represents something different in the different contexts. There is very likely also data added to those user objects in each service that are not even known to the user service.

Or what should I do ?

... but you should still reflect on the representation of the user data in each of your services. It might not even be necessary to build a projection of the user model (seller, buyer, etc.) in each of your services as soon as the user was created.

I would only do that if I needed to have some user information at hand already inside, for instance, the product service when I have to perform some domain logic. There is a good chance you only require the id (or let's say unique username) of the corresponding user in one of your services to connect a user to some domain entity. Or you could even create the corresponding user object on demand, e.g. during a checkout process.

Andreas Hütter
  • 3,288
  • 1
  • 11
  • 19
  • I want to ask something. Let say I have a basket service which store products read-only. Products sync with events. Basket service doesn't need product service availability but eventualy consistency.. Or An aggregator gateway service get product from product service and other services with strong consistency (consistency is important for stocks or prices in basket service) . Which one ? – eren arslan Sep 26 '20 at 22:39
  • 1
    If you can strive for eventual consistency or strong consistency cannot be answered in general. That is something you need to decide based on your business requirements. If eventual consistency is okay you can distribute product updates via events (e.g. with a messaging infrastructure) across other services which update their own data storage based on the received events. Or you can look into an orchestrated approach of distributed transactions and look into the [saga pattern](https://microservices.io/patterns/data/saga.html). – Andreas Hütter Sep 27 '20 at 05:00
  • 1
    If you really need strong consistency (not eventual) you may need to rethink or service boundaries. Strong consistency should be guaranteed within a service. You could merge services where this is required or you could query the crucial data on demand from the Microservice which owns it. But with this you would lose the benefits of availability and scalabilty because, for instance, the Basket service would be dependent on calling the product service for all it's actions. – Andreas Hütter Sep 27 '20 at 05:12
  • 1
    From my personal experience it is often better to be aware of the possible stale data situations and be able to deal with it rather than trying to avoid it. Usually it should not happen that often. If you publish changes via events there is good chance it happens very rarely that something is out-of-sync. – Andreas Hütter Sep 27 '20 at 05:13
1

I agree with afh answer.

A different model of a domain concept (User in this case) in every Bounded Context (BC) is the way to go. In the User BC you have the model just needed to manage the Users and its info NOT related to any other BC. In other BC you have the buying data of the buyer, the selling data of the seller and a reference ID to the User BC. Now, for optimization and isolation reasons, you could find that you need to duplicate some User BC data in Payment BC to avoid a query to another BC to accomplish some operation; then duplication it is ok.

This is a golden rule in DDD and/or Microservices. Do not try to reuse your source code models in serveral BCs (at least by default). This also aplies to the DDD roles. A domain concept (User) could be act as a Aggregate in a BC, as a Entity in other BC and as a VO in another one; so you need 3 different models in 3 different BCs.

Also remember that your views are not Domain operations. If you have to show (just show; if you need the data for rules and invariants of the BC process then this data belongs to the process BC; wich could lead to a possible data duplication) User BC data in a payment BC process you are allowed to query both BC or query a denormalized ReadModel you builded for performance purposes, etc

jlvaquero
  • 8,571
  • 1
  • 29
  • 45