Data replication in microservices

Question

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.

Answer 1

There is no right answer in architecture but to follow best practices. When you have data residing in multiple services and you have to join them , in my opinion it's not a good practice to aggregate it by calling different microservices since it kills the purpose of loosely coupled services. So in your case it's the second design.

It's not a bad practice to keep duplicated data of other services if you are going to achieve loose coupling. Another modification to your design could be use of CQRS/Event sourcing . You will dump all your events in the event store and create read-only model/projections from that event store. It's very powerful pattern but be mindful this is complex pattern and could be overkill.

Answer 2

Go with second option "copy the partial data using pub/sub". This is only way to make your microservice truly autonomous and achieve better performance by reducing network calls.