Skip to content

Caches

Django provides out-of-the-box support for configuring and using various cache systems with the web server. Typically for a single-tenant web app, there could be zero or more caches configured as part of the CACHES dictionary.

Example:

# settings.py

...
CACHES = {
    "default": {...},
    "alias-1": {...}
}
...

Now in the context of a multi-tenant web app, the following scenarios are possible:

  1. All caches defined are tenant-specific and located in respective tenant environments.
  2. Some caches could be tenant-specific while others could be centrally located.

Combining both the above scenarios, the configuration above would have to be expanded as follows:

# settings.py
# assume that 'tenant-1' and 'tenant-2' are the respective tenant ids.

CACHES = {
    # 'default' cache is centrally located
    "default": {...},

    # 'alias-1' cache is located in
    # the tenant-specific environment. 
    "tenant-1-alias-1": {...},
    "tenant-2-alias-1": {...}
}

As a consequence of the above configuration expansion, the following problems occur:

  1. It is not possible to hard-code the configurations for the respective tenants as mentioned above, as tenant configurations can be added/changed dynamically and so they will have to be updated at runtime without a server restart.
  2. In an already existing code base, any access to a particular cache would have been done as follows:
    ...
    from django.core.cache import caches
    cache = caches['default']
    # some cache ops to follow
    ...
    
    All places where access to cache has been made in the above way has to be refactored to include the tenant_id prefix as applicable. For eg:
    ...
    from django.core.cache import caches
    
    # The following line 
    cache = caches['alias-1']
    
    # would have to be refactored into
    cache = caches['tenant-1-alias-1']
    ...
    
    Also since such access could be made from a view, the tenant_id prefix would have to be picked up dynamically as well from the current request context.

Both the above problems have been solved auto-magically by the library. In order to discern which aliases are to be treated as reserved, the TENANT_ROUTER_CACHE_SETTINGS has to be configured. For details about how to configure this setting, click here