Can/should SignalR Backplane be used to build a distributed cache?

Question

Our web app uses in-memory caching (Application Data Caching) to improve throughput such that frequently queried data does not have to be loaded from the database (SQL Server) for every request. Potentially, it will be deployed in a web-farm so we have to solve the classical problem of having to synchronize the caches of all nodes. So what we need is a distributed cache.

Readily available solutions are NCache and REDIS (and probably more). However, since we are already using SignalR Backplane to communicate changes to our dataset to a Windows Service (and browser clients), I'm wondering if it could be used to implement a distributed cache.

Doing so, we would (more or less) re-use our existing dataset-has-changed messages but subscribe to them in the web app itself to invalidate its cache. The upside being that we don't have to introduce a new library/technology.

I guess my biggest questions are: Does that make sense? And, is SignalR Backplane reliable enough to make sure no events get lost resulting in out-dated caches? Or is this architectural misuse?

Answer 1

Signalr is for realtime solution not for static.

In your solution, you will select data on one service, and you will send it to another service by backplane. Then what ? Probably you will save this to memory. What happens if one of the service has restarted ? Data will gone. You will never face this problem with redis. Additionally, you will consume your local memory for this data.

Also how you will manage expiration ? Plus you will make effort to implement this cache system with signalr.

I don't suggest you to use signalr backplane for this. Stick with Redis or smilar technologies.