0

I have three microservice that needs to communicate between each other. Microservice-1 is incharge of the data and the database(he writes and read to it). I will add a redis cache store for Microservice-1 to cache data there. I want to put a redis-slave for the other 2 microservices to reduce communication with the actual microservice, if the data is already in the cache store. Since all updates to the data, has to go thru the Microservice-1 and he will always update the cache, redis replication will make sure the other two microservices will get it too. Ofcourse, if the data is not in cache, it will call the Microservice-1 for the data, which will update the cache.

Am i missing something, with this approach ?

Ash_this
  • 53
  • 5

1 Answers1

1

This will definitely work in the "sunny day" case.

But sometimes there are storms, and in storms there's a chance of losing cache coherency (i.e. the DB and Redis disagree on the data).

For example, lets say that you have Microservice-1 update the DB and then update Redis. What happens if there's a crash between updating the DB and updating Redis?

On the other hand, what if you reverse the ordering (update Redis and then the DB)? Now Redis could be updated and not the DB.

Neither of these in insurmountable, but absent a means of having a transaction which ensures that 0 or 2 of Redis and the DB are updated, there will always be a time window where the change is in one but not the other. In that situation, it's probably worth embracing eventual consistency (e.g. periodically scan the DB and update redis with recently updated records).

As an elaboration on that, a Command Query Responsibility Segregation with Event Sourcing (CQRS/ES) approach may prove useful: Microservice-1 gets split into two services, one which takes commands (requests to update) and another which handles queries. Instead of updating a row in a DB, the command service now appends (in a typical DB, an INSERT) an event which describes what changed. The query service can subscribe to those events and update Redis. Other microservices can also subscribe to the stream of events and update their own views (which can be remixed in any way they want) of Microservice-1's state.

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
  • Yeah, the other option i was thinking is using debizium to produce events on changes to db and updating the redis instances for microservice2 and microservice3. I was wondering, why do that, if redis-replicas will take care of that for me. Redis knows when its master has lost connection to the slave, if it does, i can directly go to the CQRS/microservice1 and get the data directly from the db. – Ash_this Apr 15 '21 at 21:50
  • 1
    The Redis master losing connection to the slave isn't the consistency problem (I'm assuming that Redis master/slave replication works). The problem is keeping the DB and Redis consistent, since to my knowledge, there's no way to use a transaction to make the joint update atomic. – Levi Ramsey Apr 16 '21 at 18:00