Mediatr - Where is the right place to invalidate/update cache

Question

This question stems from this other question I had asked about too many interfaces, QCRS and Mediatr library (request/response)

Mediatr: reducing number of DI'ed objects

I have created bunch of commands and queries and I have bunch of behaviors and one of them being is a Cache behaviour that for every query, cache is checked for the value before the query is actually executed against the db. So far this is working great, but the delima comes in when I have an UpdateSomethingCommand, once I update the underlying object in the db, I would like to refresh the cache with what was successfully saved to the db.

My question is specifically when to actually update the cache:

1. In the UpdateSomethingCommandHandler (this might be breaking the SOLID principal)
2. Call another command in UpdateSomethingCommandHanlder that is specifically designed to update caches (not sure this is a good design principal)
3. Introduce another behavior that is specifically designed for updating caches (not sure how to go about this yet)
4. Is there a better solution?

Answer 1

We had a similar need on a project that uses MediatR and ended up incorporating caching into the mediator pipeline, including cache invalidation as you describe.

The basic premise is that we have two different behaviors inserted into the pipeline, one for caching a response from a request, and one for invalidating a cached request response from a different request.

There is a little bit of interplay between the two behaviors in the fact that they need to exchange a cache key in order to invalidate the correct request.

I've recently pulled some of this work into a stand-alone library that in theory can be dropped in as-is to any project using MediatR. In your case, you may just want to look at the techniques we've used here and recreate them as needed.

Rather than repeat everything here and now, I'll point you at the project page where there is some documentation under the Getting Started link on the homepage: https://github.com/Imprise/Imprise.MediatR.Extensions.Caching

In my opinion, the cache invalidation makes the whole process extremely simple and straightforward, but there are cases where we needed finer control over when the invalidation occurs. In these cases the other approach we have taken is to inject an ICache<TRequest, TResponse> cache into INotificationHandlers and then call _cache.Remove(key); manually as needed. Then, from any requests you know should invalidate just raise a notification that is handled by the INotificationHandler e.g. _mediator.Publish(SomethingUpdated);

Answer 2

My suggestion is to use a cache behavior that acts on requests that implement some sort of ICacheableRequest marker interface and invalidating the cache as a step in the corresponding Update/Delete command handlers (like you mentioned in point 1).

If you choose to create an invalidator behavior there are a few problems.

First, it's unclear that the command is invalidating the cache. Whenever I need to check what's going on when an entity is updated/deleted, I just follow the command handler, there are no side effects (harder to follow) by creating a separate cache invalidator.

Second, even if putting the invalidation code in a separate file follows better the SRP, you will have to choose where to put the cache invalidator class. Does it go next to the cached query or next to the command handler that invalidates the cache?

Third, in many scenarios you won't have enough information about the key used to cache the request in the associated command, you'll only get that and any other extra invalidation condition in the CommandHandler.