0

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... – Clockwork-Muse Feb 16 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 Feb 18 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.