Keep microservices data consistent

588 views Asked by At

Our current project is based on a microservices architecture. So far so good, but we started to approach a way to keep all of them in a consistent state in terms of data.

Basically we split them according to our main entities in the solution. Those entities can work independently quite well but there's still some dependencies between them, which involves update a set of microservices when an entity from another microservice is modified.

We tried to tackle this challenge through different routes. At first, we considered rabbitmq to be a good solution for this problem: a microservice sends a message with the change information to an exchange that fan outs it to the consuming microservices queues. Something like this:

enter image description here

It seems a good solution, but we are a little bit worried about the data consistency if an error arises in any of the consumers: we would need to implement a strategy for reverting back those changes across all the consuming microservices. Also were considering a brokerless technology such as ZeroMq that could do the same trick without having the broker bottleneck.

We also thought of masstransit routing slip pattern implementation as a possible solution, so we could compensate all these errors in an easy way, but we are not that fond of having a sequential set of activities consuming these changes. We rather have the same approach we got on rabbitmq, where consumers are working in a more parallel way.

So right now we are in kinda of an impasse and we were wondering what other developers have chosen as a solution for this problem. We don't discard other technologies if those get to solve this issue.

1

There are 1 answers

0
Saravanan Subramanian On

This is one of the main drawback of microservices architecture. I can think of:

  1. Implement a feedback loop machanism using a shared database. For example, if service A, sends an update to B, C & D. Once B,C & D comples the operation they should update the DB. If the update is not done within a timeout period, based on the status update, service A could trigger a reverse operation or any other corrective action decided by the business logic.

We have the above implementation to solve the above problem.

You can read my article to understand microservices design principles :

https://techietweak.wordpress.com/2015/07/05/mdp/

Thanks.