Multiple Cache backends in Django

If you are reading this article, I believe, it’s safe to assume you have at least a basic knowledge of what caching is.  Hellokea is built using the Django framework. At the time of this post, our front end is also built and managed using Django.  We are pretty happy to use Django’s admin feature for posting our blog posts and other resources. Most of the time, the website loads with a decent speed passing all Google’s page insights. There are times when loading the front page of the website could take a couple of more milliseconds when the servers are busy serving our users. This is where caching shines.

Redis and Cache

Redis is our primary go-to server for caching, WebSockets and queuing. For processing backend tasks, Celery along with Redis is used for queuing tasks. We are still in the early stage of development serving very few customers, and managing different caches is kind of an overkill. Every single operation is allocated a different Redis database. For eg: Celery queues use Redis Database 1, WebSockets uses Redis database 2 and so on.  Django cache is fantastic at handling multiple cache settings. Configuring cache in Django is through the settings file.

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
    }
}

The above snippet is a sample for using Redis Cache in Django. In our case, we use multiple caches like

CACHES = {
   'public_website': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
    },
    'sockets': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/2',
    },
    'feed': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/3',
    },
} 

To access any of the caches, all you have to do is either use the cache_view decorator per view basis or do it manually.  Now, let’s take a real-world scenario as an example. This website page you are reading uses thecache_view decorator to store the computed blog post information in the Redis database on 1 which is  public_website.  The website is cached for a minimum of 15-30 minutes depending on the page. What happens when we have to update the page? We have to clear the cache and update it with the latest data from the database.  The interesting part here is clearing the cache.

Clearing caches

Though cache could improve the speed of the website, there would be a scenario where you have to invalidate the cache data to get an updated one. Django makes this so enjoyable. A classic example is when creating or updating a page or a blog post on the website. When updating or creating, override the model save method, assuming you are managing it through admin, to invalidate the cache.

from django.core.cache import caches

public_cache = caches["public_cache"]
public_cache.clear()

The snippet clears all the cache associated with the public_website. It’s totally up to your logic to decide on invalidating the cache. Generally, pages which are rarely updated could easily be cached for a very long period of time thereby reducing the database hits. We do have actions in the admin panel to clear caches if there are any changes to pages.