CODEWITHSUNDEEP
microservicescqrs
nader ghazi
nader ghazi

Reputation: 56

what to do when CQRS pattern in Microservice architecture leads to a monolith data structure

i'm trying to learn Microservices by implementing a sample project, tried to pick a semi-complex one to face real world challenges in Microservice architecture. this is a simplified version of the project flow that I designed till here: the flow as you can see in the image I'm trying to get the list of appointments for a specific company, but since the required data is inside different Microservices, for getting the appointments I have to follow these steps:

  1. the API gateway (bff) will get the request from frontend that contains a token
  2. bff will authorize the jwt token by sending it to the users ms
  3. appointments are separated by companies ids, so before getting the appointments, I need to get the user company
  4. company id will be sent to appointments to get the appointments for the company
  5. appointments will check to see if actor is authorized to get the list of appointments by its role (came earlier from the user ms)
  6. appointments will return the list of appointments
  7. inside appointments as you can see in the entities, I do have the id of both sides (sideA, sideB)
  8. bff will get those users details by the ids from users
  9. inside appointments data that is returned, there is a customer_id that is the id of a customer inside the company ms so bff send another request to the company to get the customer details
  10. inside customer details, there is an id of a project that the customer is eager to visit so, bff will send a request to get the project from the projects ms
  11. at the end, bff will join the data and return it to the frontend application.

this is also the simplified version of entities inside Microservices: entities

right now, i'm using composition API approach to get the data I need, but as you can see the flow is complicated, and I can't think of a way to implement pagination, since I might need to sort, filter and then paginate the data, so I think in this situation, this might be a good idea to use CQRS pattern, but the problem is since I have many situations like this, I have to implement lots of CQRS services.

I'm wondering if:

  1. is it possible to create a single CQRS service to have all the data for read purpose, instead of CQRS for each situation?
  2. for some situations like this, the CQRS read database will becomes almost identical to a monolith architecture db. is. this okay?!
  3. is there any alternative way to scape the complexity of creating and managing multiple CQRSs with partial repetitive data?

Upvotes: 2

Views: 808

Answers (1)

Mahadev K
Mahadev K

Reputation: 350

CQRS will help you get all the required details in one call. A CQRS service will have multiple tables that are part of different microservices.

An example will be like "OrderViewService" will require to listen and store events from "OrderService", "DeliveryService", "AccountingService". But it wont be listening to multiple other services which are not of concern for "OrderViewService". So the point I am making here is the database won't become so similar to the monolithic database as it would have a lot more details.

For your project you might require a single CQRS that may deliver your requirements. As it seems your requirements have dependency on all of the microservices and so a single CQRS service could help you solve the requirements.

Also if you are concerned about the space make sure what details would be required were only be saved to the view/read CQRS database. Thereby ensuring that we are not overwhelming the db with all the details from all the services.

As application grows there can be multiple CQRS services listening to different services or a combination of services and thereby serving their responsibilities.

Reference - https://microservices.io/patterns/data/cqrs.html

I think this explains and these are my thoughts about CQRS. Let me know if you have any questions post it as comments.

Upvotes: 1

Related Questions