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.

  • 1
    .... if your items can be updated, and you only store the ids, you must be able to retrieve the history of the item, or weird stuff results. Among other things, you will almost never be able to pull price from such a service - you have to store exactly what you charged your customer at that point in time, and this might include manually adjusted offers (ie, "I'mma give just you a special deal"). Which is why transactions are probably usually a full, completely duplicated, record - so you can guarantee an accurate representation of the exact order made, not hope nothing was updated... Commented Feb 16, 2019 at 0:20
  • Yes I agree with you about the price, and for that i will have to store the price in the transaction service. Maybe I gave a wrong example. Lets assume that there is an other service where i have ids (foreign keys from other service), and I always want the updated data there. Which method would be better in that case
    – pratikvasa
    Commented Feb 18, 2019 at 6:51

1 Answer 1


Microservices must own the data they are working on.

Your first approach basically suggests a database-microservice. This is not a good idea, and performance is not the only reason why. You are creating a gigantic dependency magnet, and a single point of failure for the entire application.

In many cases, you actually want to store the relevant historic information for business reasons. But let's consider the case where you really do want to work on the latest data. A good example for this might be a Search service.

It is quite likely that the data-storage requirements of your search service are quite different from those of the product catalog - or your other services for that matter. You probably don't need history data, you might not need all data, you may want to store word frequencies, relate it to mentions on your blog or referrals, and so on.

By giving the Search service ownership of the data, you allow the team to choose the optimal approach and technology based on the specific needs of this particular service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.