How to Transfer Data Between Multiple Microservices?

Question

As part of my project, I'd like to use microservices. The application is a store website where the admin can add products and the user can order and buy them. I envision implementing four services: admin service, user service, product service, and order service. I had trouble with handling data between multi services but it's solved by duplicating some necessary data using message brokers. I can do this solution between product and user and order service because I need some of the data not all of them Now, my question is about handling admin service because in this service I need to access all of the data, for example, the admin should have a list of users and the ability to add new products or update them. how can I handle data between these services and the admin service? should I duplicate all data inside the admin service? should I use Rest API?

Answer 1

no thats wrong. it seems you want run away from the fact. in general duplication is an anti-pattern mostly in case you describe. the way you thinking about admin-service is wrong.

because in this service I need to access all of the data

i dont think you need to have such a service. accessing the data based on users must be handled by Identity server(oidc Oauth) which is the separated service and handle the accessing end points .

for example the product-service provides 1-return product list 2-return individual product data 3-create data. the first two can access by both user and admin but the 3rd must be accessed by admin. one of identity server duty is to identify user in case of user interaction(login) with services.

ADMIN Scenario

1. user-client request create product endpoint(services eg:product.service).
2. client-app(front end app) is configed with identity server and realize there is no require identity tokens and redirect to identity server login.
   NOTE: there is also identifying the client-app itself i skipped.
3. user-client login and get require token that based on his claims and roles and etc.
4. user-client request create product endpoint with tokens included in request header
5. endpoint (product service) receives the request and check the header (the services also configured base on identity server and user claims)
6. get the user claims info.
7. the create-product requires admin role if its there then there we go otherwise no access.

the image uses identity server 4 . there are also several kinds and also you can implement by your self using 0AUTH and oidc protocol libraries.

so the admin just request to the certain service not getting data through the separate service for this goal.

Communication between Service:
the most struggling part of microservices is the wiring it up. the wiring is directly the consequence of your design.(recommand deep study on Domain Driven Design).

asynchronous communication :
to avoid coupling between services mostly use asynchronous communication which you pass event eg:brokers like rabbitmq and kafka..etc , redis etc. in this communication the source service who send event does not care about response and not wait for it.just it always ready to listen for any result event. for example

1. the inventory service creates item

123|shoe-x22|22units

and this service fire event with data 123|shoe-x22(duplicate maybe or maybe not just id) to product service to create but it does not wait for response from product service that is it created successfully or not.
as you see this scenario is unreliable in case of fault and you need handle that so in this case you have to study CAP theory,SAGA,Circuit-breaker.

synchronous communication :
in this case the service insist to have response back immediately. this push service to become more coupling. if you need performance then you can use gRPC communication other wise simple api call to the certain service. in case of gRPC i recommand using libraries like MassTransit

which also can be used for implementingf gRPC with minimum coupling.

Some of Requests need data from multiple services
if you are in such situation you have two options.

1. mostly microservices architecture using APIGATE WAY (EG:nginx,OCELOT,etc) which provide reverse-proxy,load balancing,ssl terminations etc. one of its ability is to merge the multiple responses from a request.but it just merge them not changing the data structure of response.

2. in case of returns desire response data structure you may create an Aggregator service which itself calls other two, gathers data and wrap it in desire format and return it.

so in the end still the Domain Driven Design is the key and i think i talked tooooo much. hope help you out there.