how to handle duplicated data in a micro service architecture

Question

I am working on a jobs site where I am thinking of breaking out the jobs matching section into a micro service - everything else is a monolith.

But when thinking about how the microservice should have its own separate database, that would mean having the microservice have a separate copy of all the jobs, given the monolith would still handle all job crud functionality.

Am I thinking about this the right way and is it normal to have multiple copies of the same data spread out across different microservices?

The idea of having different databases with the same data scares me a bit, since that creates the potential for things to get out of sync.

Answer 1

You are trying to go away from monolith and the approach you are taking is very common, to take out part from monolith which can be converted into a microservice. Monolith starts to shrink over time and you have more number of MSs.

Coming to your question of data duplicacy, yes this is a challenge and some data needs to be duplicated but this vary case to case and difficult to say without looking into application.

You may expose API so monolith can get/create the data if needed and I strongly suggest not to sacrifice or compromise data model of microservice to avoid duplicacy, because MS will be going to more important than your monolith in future. Keep in mind you should avoid adding any new code to the monolith and even if you have to, for data ask the MS instead of the monolith.

Answer 2

One more thing you can try, instead of REST API call between microservices, you can use caching mechanism with event bus. Every microservice will publish CRUD changes to event bus, interested micro-service consume those events & update local cache accordingly.

Problem with REST call is, in some situation when dependent service is down we can not query main microservice, which could become bottleneck sometime.