What is the difference between 2nd level option and backplane, when using distributed cache?

[askids]

hi,

I would like to understand the difference between using the 2nd level option (of using a distributed cache) and Backplane with distributed cache? Somehow both of them looks same to me. How are they different?

Also, for distributed cache, you mention that any backend that supports IDistributedCache can be used. However for backplane, only Redis is supported, not the others which support IDistributedCache. Why is that?

Thanks!

[jodydonetti]

Hi @askids and thanks for considering FusionCache!

I would like to understand the difference between using the 2nd level option (of using a distributed cache) and Backplane with distributed cache? Somehow both of them looks same to me. How are they different?

I'll try to do my best to dissect the 2 levels and the backplane for you: keep in mind that most points are valid in every scenario, but some are related (or more relevant) to a multi-node scenario.

The 1st level cache is an in-memory store and:

• ✅ it's always there (eg: even if the network is down)
• ✅ is very fast
• ✅ has high data locality (the data is near to where it is used)
  But:
• ⛔ it starts empty every time the app starts
• ⛔ every node may have the same data, duplicated

Also, being local to the machine it is running, it does not suffer from the fallacies of distributed computing.

The 2nd level cache is an out-of-memory store (and typically distributed, as in running on one or more other machines) and:

• ✅ it does not empty itself when each app/node restarts
• ✅ the data inside is shared between all nodes
  But:
• ⛔ it may not be always there (eg: if the network is down)
• ⛔ is usually fast, but definitely not as fast as the in-memory one
• ⛔ the data is farther from where it will be used (the cpu in each node)

Both of these are cache layers, which means they are store (as in, places where the data is stored) and the idea is that combining both you get the best of both worlds:

• ✅ it's always there, at least the 1st layer
• ✅ is very fast (the 1st layer is used first, the 2nd is used in background so it will not slow down processing)
• ✅ has high data locality (from the 1st layer)
• ✅ it does not empty itself when each app/node restarts (the 1st layer gets automatically populated from the 2nd layer)
• ✅ the data inside is shared between all nodes (on top of being inside each node in the 1st layer)

Now the only remaining problem is that sometimes you may have data inside each nodes' 1st layer that is not in-synch with other nodes' 1st layers, based on when some data have been requested.

Here is when the backplane enters the scene.

In fact the backplane is not a store (like the 2 layers) but it is a message bus onto which FusionCache sends messages to notify the other nodes about changes, so that each time something changes all the other nodes can be notified so everything remains synchronized everywhere all the times (automatically).

Also, for distributed cache, you mention that any backend that supports IDistributedCache can be used

Exactly! All the available implementations can be found here in the Packages section.

However for backplane, only Redis is supported, not the others which support IDistributedCache. Why is that?

Because the backplane needs to be able to send and receive messages (think pub/sub) and the IDistributedCache interface does not have methods to do that, so FusionCache cannot use any random IDistributedCache instance to send/receive messages.

In practice this means that I have to code a backplane implementation for every possible system out there that does have a pub/sub mechanism (since there's no IDistributedMessageBus generic interface in .NET, like for IDistributedCache) and the one I know it has such thing is Redis. I would gladly implement more if/when I find other systems. If I'm not wrong MongoDB has something similar, but I'd like suggestions from the community (and you, if you like) to see which one to implement next.

In closing I'd like to suggest a couple of readings, like the Backplane doc itself and, if you have some time, the Step By Step one which is long (so grab a cup of coffee) but I think may be a good way to go one step at a time and understand each piece of the puzzle and what results it can get you.

Hope this helps, if you have any question let me know!

[timothyeckert]

This implies that if the data isn't in the 1st level cache, when a 2nd level cache is present that the cache will fetch the data from what ever backend is in the factory rather then the 2nd level cache. Is this true, or would it try the 2nd level cache first?

Thanks!

[jodydonetti]

This implies that if the data isn't in the 1st level cache, when a 2nd level cache is present that the cache will fetch the data from what ever backend is in the factory rather then the 2nd level cache. Is this true, or would it try the 2nd level cache first?

Hi @timothyeckert and thanks for using FusionCache!

The 2nd level, if present, will be checked before calling the factory!

The order of operations, in a scenario with both 1st + 2nd level, is the following:

• check 1st level (memory)
• if not found or found but expired, check 2nd level (distributed)
• if not found or found but expired, call the factory
• if factory is executed successfully, save the result in both 1st level and 2nd level

Let me know if this answer your question.

Hope this helps!

[timothyeckert]

This was exactly what I was looking for, and the outcome I was hoping for.

Thank you for the quick reply!

[askids]

@jodydonetti thanks for explaining in detail. I will take a look at the step by step guide in details.

One unrelated question. Theoretically, can this implementation be extended to synchronize multiple Redis clusters across multiple data centers instead of typical single cluster on one data center?

[jodydonetti]

One unrelated question. Theoretically, can this implementation be extended to synchronize multiple Redis clusters across multiple data centers instead of typical single cluster on one data center?

Sorry @askids , I missed this part.

I don't know honestly. Something like multi-cluster synchronization would probably be better off handled directly by a native Redis feature itself.

Having said that, let's play with the idea a little: I suppose it would be possible to create an implementation of a backplane that connects to multiple Redis instances, so that every message would be sent to all the Redis instance automatically.

But this would help in invalidating the cache entries. Is that enough? I don't know, it depends in what you mean with "synchronize multipe Redis clusters". For example the backplane would not share cache entries themselves, so cached entries would not float from one Redis cluster to another.

But at the same time simply invalidating the changed entries would let them be reloaded from the database if needed, so... mmh, I don't know, I would have to think about it a little bit deeper, I think it can become very complex very easily, with some nasty edge case hidden here and there.