Memory cache with backplane?

[SbiCA]

Is there a way to use the memory cache but still use the backplane for signalling of changes?

The scenario I have in mind is data that can be cached in memory but you still want to be made aware if you're local cache changed. Maybe without using redis for the signaling part maybe a DB table, something like ZeroMQ could be fine you don't want to bother about running/hosting Redis

Not sure if that's a good idea in general yet 😄

[jodydonetti]

Hi @SbiCA take a look at the Backplane docs, particularly this part:

It is technically doable, but there are things to be careful about, it's nuanced.

Hope this helps.

[SbiCA]

@jodydonetti thx for the fast responsive 😲!

the scenario I had in mind would be a bit different from the one you described in the docs in our use case it would be rather static data that would be loaded initially per node and kept in memory for the whole lifetime. And I was assume that the backplane would also send along the new data to cache but that's probably something that would require an extension from what I got so far

So in my naive view it would be something like:

1. 3 nodes starting and loading all data in memory
2. Node N1 gets a change signals the new data via back plane
3. N2, N3 evict their cache and update with new data

Cheers and thx for this awesome library 👏

[jodydonetti]

And I was assume that the backplane would also send along the new data to cache

Can confirm: the backplane only sends a notification, meaning a "signal", without the actual data.
This has been a specific design decision because with multiple nodes, each of them will have its own set of data cached locally (each local memory cache is not the same as all the others, it is based on local requests received on each node), and a lot of times an updated piece of data is not present on most of the other nodes (so there's nothing to update), and/or it will not be requested again on some other nodes, so it would be a waste to update them.

Sending the data with each notification would waste a ton of bandwidth/resources, whereas with the current design all is automatically adaptive, based on the actual usage on each node.

So in my naive view it would be something like:

1. 3 nodes starting and loading all data in memory
2. Node N1 gets a change signals the new data via backplane
3. N2, N3 evict their cache and update with new data

Correct, this would work, but with a small detail: when N2 and N3 receive the notification, they will evict their cached entries, BUT they will update their local copy immediately ONLY if they have their own local cached entry for the notified cache key AND there's a distributed cache available.

Instead, if there's no distributed cache (so your case), it will simply evict the local cached entry and just wait for the first request for that cache key to update it from the database (or whatever).

Nitpicking corner: as an added bonus, if fail-safe or soft/hard timeouts are enabled, the local evicted cached entry would still be available as a temporary fallback in case of problems/delays during refresh.

Cheers and thx for this awesome library 👏

Thanks to you!

[jodydonetti]

ps: if you like, please mark the answer🙂