Once someone decides they want to use redis as something other than a cache, you sort of do have 2 cache technologies anyway. You can't use a redis instance that is configured for caching for any other purpose (caching instance must have eviction, non-caching instance must not have eviction). You need a second redis with a different configuration.

Honestly designing your app to have a "memcache-friedly cache layout" is the same thing as designing it to have a redis-friendly cache layout. The pattern for this kind of application cache is identical: "get, and if not there, calculate and set".

I tend to write an abstraction interface, if there isn't already one, where you request a key and pass an async function/lambda that will return the value from source in case of a cache miss.

    var value = cache.lookup<T>(
      keyname, 
      () => db.query<T>(...), 
      TimeSpan.FromMinutes(5) // or CacheOptions
    );

This way it can fallback/insert on a cache miss directly...

Not maintaining 2 cache technologies is always a winning argument.