0

I want to use the many to one and other DB Relationship in micro-service architecture. In monolithic architecture we can create the entity relationship easily as they belongs to same project but in micro-service architecture how we can achieve the same.

Example:

There is one userDeatil service and other is productDetail service.Now there is third service called orderDetail and an order will have userID and ProductIDs associated with it. So how can we manage the relationship between 'user and order' and 'order and product'.

I have searched over net but didn't able to get the fair idea.There is another thread having same query but not having the clear answer. Link

Nishant Varshney
  • 685
  • 2
  • 14
  • 34
  • Each microservice should have it's own db schema and as few dependencies to other services as possible. If you think about relationships of microservices then your bounded contexts are wrong or microservices is not the architecture that fits your requirments – Simon Martinelli Feb 04 '19 at 09:27
  • @SimonMartinelli This is what I came across after search over the web aswell. could you pls suggest how can we implement the problem statement asked in the question..or we can not achieve this with micro services architecture? – Nishant Varshney Feb 04 '19 at 10:03
  • You should first read about microservices and then think about if it solves your requirments https://martinfowler.com/articles/microservices.html – Simon Martinelli Feb 04 '19 at 10:04

1 Answers1

1

In my opinion your case is about how you specify your services especially how you define the bounded context of each service !!

According to the situation above-mentioned I don't see any reason why the product service should know anythings about orders (even if it s just the order-id) and backwards. One more problem I see in this case: your services will not work if one service is not available (E.g when the product service it not online, your order service will not be able to work, because he needs the product details from the product service...).

I Think you should rethink the bounded contexts of your microservices. You should keep in mind:

  • ensure a loose coupling of the microservices
  • a microservice has always to work even other Microservices are not available (Resilience / Reliability).

The DDD (domain-driven-design) paradigm with its tools provides her a great help to assist you, during the definition process of your services, you encourage these qualities.

So, the following is JUST an idea (it s not a recommendation and you should review whether it matters for your business case) :

  • It seems like the "order" process is your core business domain. So you have to focus on it.
  • The user service (i hope you mean here the customer and not a user in terms of authentication/authorization) has only the responsibility to manage the customers, and may be their adresses, bank-Accountings etc.. It should not know anything about your orders or products.
  • The same is valid for the product service. It owns only data about products. It has no relation either to the customer nor to the order-service.
  • The order service by itself deals only with orders and should own only data that belong to an order (like ship Adress and some information about the product-items ordered). I think the customer-Id is also important here to keep the relation between the order and the customer. This way you can e.g get all orders made by a certain customer-id....
Najib Bakahoui
  • 41
  • 4
  • I got your point... but how we will manage a condition to check that the given userId for order service is valid or not? same as given productID is valid or not??In this case I can get the status of user or product from respective micro service but if any one of them is down we will not be able place our order?? Is it correct design idea?? – Nishant Varshney Feb 07 '19 at 13:07
  • Keeping data consistent in a distributed system is always a challenge. In the world of microservices there is meanwhile some good patterns that help solving problems related to data management/consistency. A good site describing the patterns is e.g https://microservices.io/patterns/index.html) – Najib Bakahoui Feb 08 '19 at 15:26
  • Some known patterns are e.g the SAGA and the API-Composition. The last one may be sufficient in your case: You should have a component (an API-Gateway) that encapsulates & orchestrates all calls to your microservices. E.g during the order process, it calls first the user- and product services to check if the user and the products are valid. Only if its the case it will then call the order service to place the order. This way you ensure that the data (at least during the creation of the order) is consistent. – Najib Bakahoui Feb 08 '19 at 15:26