title: Cache invalidation in CQRS application
body: <p>We practice CQRS architecture in our application, i.e. we have a number of classes implementing <code>ICommand</code> and there are handlers for each command: <code>ICommandHandler&lt;ICommand&gt;</code>. Same way goes for data retrieval - we have <code>IQUery&lt;TResult&gt;</code> with <code>IQueryHandler&lt;IQuery, TResult&gt;</code>. Pretty common these days.</p>
  
  <p>Some queries are used very often (for multiple drop downs on pages) and it makes sense to cache the result of their execution. So we have a decorator around IQueryHandler that caches some query executions.<br>
  Queries implement interface <code>ICachedQuery</code> and decorator caches the results. Like this:</p>
  
  <pre><code>public interface ICachedQuery {
      String CacheKey { get; }
      int CacheDurationMinutes { get; }
  }
  
  public class CachedQueryHandlerDecorator&lt;TQuery, TResult&gt; 
      : IQueryHandler&lt;TQuery, TResult&gt; where TQuery : IQuery&lt;TResult&gt;
  {
      private IQueryHandler&lt;TQuery, TResult&gt; decorated;
      private readonly ICacheProvider cacheProvider;
  
      public CachedQueryHandlerDecorator(IQueryHandler&lt;TQuery, TResult&gt; decorated, 
          ICacheProvider cacheProvider) {
          this.decorated = decorated;
          this.cacheProvider = cacheProvider;
      }
  
      public TResult Handle(TQuery query) {
          var cachedQuery = query as ICachedQuery;
          if (cachedQuery == null)
              return decorated.Handle(query);
  
          var cachedResult = (TResult)cacheProvider.Get(cachedQuery.CacheKey);
  
          if (cachedResult == null)
          {
              cachedResult = decorated.Handle(query);
              cacheProvider.Set(cachedQuery.CacheKey, cachedResult, 
                  cachedQuery.CacheDurationMinutes);
          }
  
          return cachedResult;
      }
  }
  </code></pre>
  
  <p>There was a debate whether we should have an interface on queries or an attribute. Interface is currently used because you can programmatically change the cache key depending on what is being cached. I.e. you can add entities' id into cache key (i.e. have keys like "person_55", "person_56", etc.).</p>
  
  <p>The issue is of course with cache invalidation (naming and cache invalidation, eh?). Problem with that is that queries do not match one-to-one with commands or entities. And execution of a single command (i.e modification of a person record) should render invalid multiple cache records: person record and drop down with persons' names.</p>
  
  <p>At the moment I have a several candidates for the solution:</p>
  
  <ol>
  <li>Have all the cache keys recorded somehow in entity class, mark the entity as <code>ICacheRelated</code> and return all these keys as part of this interface. And when EntityFramework is updating/creating the record, get these cache keys and invalidate them. (Hacky!)</li>
  <li>Commands should be invalidating all the caches. Or rather have <code>ICacheInvalidatingCommand</code> that should return list of cache keys that should be invalidated. And have a decorator on <code>ICommandHandler</code> that will invalidate the cache when the command is executed.</li>
  <li>Don't invalidate the caches, just set short cache lifetimes (how short?)</li>
  <li>Magic beans.</li>
  </ol>
  
  <p>I don't like any of the options (maybe apart from number 4). But I think that option 2 is one I'll give a go. Problem with this, cache key generation becomes messy, I'll need to have a common place between commands and queries that know how to generate keys. Another issue would that it'll be too easy to add another cached query and miss the invalidating part on commands (or not all commands that should invalidate will invalidate).</p>
  
  <p>Any better suggestions?</p>