CACHING.md

Caching

Plio uses the Redis cache backend powered by the Django Redis package.

This guide aims to provide details on how Plio is using caches and serves as a pre-requisite for someone contributing to the code.

Caching workflow

Plio's caching mechanism can be explained in three simple steps:

1. Receives an API request
2. Searches for the requested data in the cache
3. If data is present in cache, return the cached data
4. If not present, query the database and save the response in cache for future requests

Caching workflow explained via flow diagram

Cache keys

The calculation of the cache keys are based on the model instances. For example, an instance for plio ID: 1 will have plio_1 as the cache key. For more details, check out the get_cache_key function in plio/cache.py.

Cache invalidation

When a particular instance is updated, its cached value gets deleted along with the cache of any other related instances that depends on this cache. For example, consider a user instance cache that uses an organization instance cache (as the organisations that the user is a part of is included in the user response). Now, if the organization is modified, the caches for both the user instance and the organization instance will be deleted.

The new cache will be set when the first fresh response is calculated from the database and will be used for subsequent requests.

Cache invalidation explained via flow diagram

Current cached data

We have only implemented caching for models with a high number of GET requests. The following resources have been cached:

1. Plio

   • Plio cache is created when there is a retrieve request for a plio instance.
   • Plio cache is re-created when there is a create, update or delete request for a plio instance.
   • Plio cache is deleted when there is a create, update or delete request for any of the following related instances for a plio instance:
     • Video
     • Item
     • Question
     • User

2. User

   • User cache is created when there is a retrieve request for a user instance.
   • User cache is re-created when there is a create, update or delete request for any of the following related instances:
     • User
     • OrganizationUser (as the UserSerializer is called when OrganizationUser is modified)
   • User cache is deleted when there is a create, update or delete request for any of the following related instances for a user instance:
     • Organization

For more details on the caching implementation for above, refer to the corresponding serializers.py files.