[QUESTION] Management of 2 redis caches (behind fusioncache) for HA

[sabbadino]

Hi, we have our app deployed in west and north europe for HA.
As of now they both share the same azure redis cache.
We were considering to have 2 redis caches , one in north and one in west .. having north app pointing to north redis and west app pointing to west redis.

I am not that worried about the increment of cache misses. My "problem" is when i need a cache entry invalidation (e.g. when i cache user permissions and they are modified in the backoffice of the app by the admin).
I don't think it comes out of the box.
What comes to my mind is to register both redis instances as named fusioncaches. The west app will use the named one linked to redis west for all calls , but when it has to call Remove/Expire: In this case it will send the command to both named caches.

Does it makes sense ? Is there a better way ?

thanks Enrico

[jodydonetti]

Hi @sabbadino , sorry for the delay.

This is a scenario I'm thinking about for some time, and there are different ways to tackle it.

Now that v1.4.0 is out I think I can try to come up with something... will update.

Meanwhile, a couple of questions.

Hi, we have our app deployed in west and north europe for HA.
As of now they both share the same azure redis cache.

Question: are the 2 app instances behind the same hostname, with a load balancer/gateway in front of them or are they reachable separately?

We were considering to have 2 redis caches , one in north and one in west .. having north app pointing to north redis and west app pointing to west redis.

Would they connect to the same db instance?

My "problem" is when i need a cache entry invalidation (e.g. when i cache user permissions and they are modified in the backoffice of the app by the admin).

Would the admin app also be deployed in 2 different regions? If so, behind the same hostname with load/balancer etc (see above).

I don't think it comes out of the box.

Correct, as of today no.

What comes to my mind is to register both redis instances as named fusioncaches. The west app will use the named one linked to redis west for all calls , but when it has to call Remove/Expire: In this case it will send the command to both named caches.

On top of Remove/Expire, also Set!
And, in theory, the "Set" part of a GetOrSet but this may be... complicated, so (continue below)

Does it makes sense ? Is there a better way ?

Maybe another idea to try out is to listen for Set/Remove/Expire events on the "primary" cache of the region, and for each event trigger an eviction on the other one. I'm not 100% sure there will be no hiccups, I'd have to play with this and think about it more, but it's something you can play with and see how it goes.

I'll think about it a little more, let me know if you try something like this.

[sabbadino]

Question: are the 2 app instances behind the same hostname, with a load balancer/gateway in front of them or are they reachable separately?
Answer: they are in two different regions , traffic is routed 50 50 via a traffic manager.

Question: Would they connect to the same db instance?

Answer's Now they are (all using the west instance). The plan is to have north region web app pointing to north region redis and west Europe web app point to west Europe redis.
The two redis does not share anything.

Question ' Would the admin app also be deployed in 2 different regions? If so, behind the same hostname with load/balancer etc (see above).

Same as question 1 : two different regions for HA.

You say : On top of Remove/Expire, also Set!

I am not that concerned about the set .. that is , not that concerned to lower the cache hits.
It's the invalidation my main concern.

You say :
Maybe another idea to try out is to listen for Set/Remove/Expire events on the "primary" cache of the region, and for each event trigger an eviction on the other one.

goid idea : leveraging events makes the app code unaware of this "forwarding" .

My intent is to have not a primary.
Suppose the request for a change of user permission hits the west region instance web app : the admin module in west send a remove command to FC pointing to west redis , and a listener on this FC event send a remove command to north redis directly (not via fusion cache). the question is : will the backplane setup in north web app instance will propagate the eviction to north instances memory cache ? in other words the eviction backplane command is triggered by redis or by the application using redis ?

Enrico