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

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.