Why We Are Moving To Redis

Memcache is a bit of a black box when it comes to caching. It is very hard to tell what is in it and how we are using it. For this reason, we have chosen to switch to using Redis for our application cache. Redis will allow us more insight into how we are using the cache and give us more control over our cache keys. It also has nice features such as background deletion and Lua scripts to handle complicated logic. Plus, if we ever want to use a worker/job service such as Sidekiq it can act as a datastore for that.

Strategy For Moving Keys

In order to move to Redis, we will be doing it one key at the time for the most part. This will ensure that a large cold cache doesn't slow things down. This will also help us to evaluate how we are using the cache and ensure that each use is still needed.

In this PR I set up a second cache store RedisRailsCache that behaves just like Rails.cache but instead points to Redis. The goal will be to replace all Rails.cache calls with RedisRailsCache and then eventually switch Rails.cache to point at Redis.

How You Can Help!

There are a lot of cache keys that need to be moved and I would rather move them one by one to minimize risk which is why I would love help with this project. Feel free to grab a cache key and roll it over to Redis!

Considerations for moving a key

• Can this cache safely become cold?
• Does this cache key make sense? Is there a better/more clearer one?
• Should this be a cache at all? There might be places where we can live without a cache and simply removing it might be the best move rather than switching it to Redis.
• Does the current expiration make sense?

Example PRs

https://github.com/thepracticaldev/dev.to/pull/4684https://github.com/thepracticaldev/dev.to/pull/4685