We are trying to move from a monolithic architecture to a microservice architecture. We thought of what would be the best way to segregate our services and started doing so one by one. Now we have a question as to how we should make dependent calls. Let me explain in detail.
Lets say we have different microservices. One of them has details about a product. Other microservices revolve around the product, so they will be a service for transactions, orders, offers etc. All microservices communicate using gRPC.
All these services will be referencing the items microservice that has details of the items (referencing will be done via IDs). So each of the other services will only be having the ID of the Item.
Now the issue (or maybe not) is that when ever we want to see a list of transactions done by a user, we also need details of the items. Similarly list of orders places, again we need details of the items. (not all the details but some of them).
There are two options that we can think of for dealing with the issue.
One is to make two subsequent calls, once to the transaction or order microservice and than to the item microservice to get the partial details needed. Here we have our own gateway which is extremely efficient in terms of performance and network.
The other is to copy the partial data using pub/sub that is required by the transaction and order microservice in the service itself. So basically something like a new table in the order microservice and taking a join in the service to serve data. thus killing the need to make dependent calls.
So first of all is the segregation of the services proper?
second which of the 2 methods are a better design
Note: we have around 10 services that would be dependent on the items database. Also on a page there are usually calls to 5-6 microservices. The good thing is that we have our own gateway which makes all calls in parallel. So there will be max 2 sequential calls if we use the first method.