Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


Overview

Use of caching for sending Response for the API which are most used and have least frequency of  update of underlying data.


Benefits :

  1. It will reduce the load on database and also improve response time.
  2. Will able to keep up all the supported API alive in case of database failure.

Disadvantage :

  1. Some time may return old data if a concurrent read write operation happen in a time span of Redis update time , Redis update time means time taken by Redis to update data into the cache after a successful update API call. It will very rarely possible.



Following is List of API's which will supporting Redis Caching.

Respective keys are also mentioned for a read with a particular id.

API ENDPOINTKEY
/v1/user/read/:uiduserId
/v2/user/read/:uiduserId
/v1/user/getuseruserId
/v1/role/read
/v1/user/course/list/:uid userId
/v1/org/readorgId
/v1/page/read/: pageIdpageId
/v1/page/section/listpageId

/v1/page/section/read/:sectionId

sectionId

/v1/course/batch/read/:batchId

batchId

/v2/dashboard/progress/course:batchId

batchId

/v1/system/settings/get/:field


/v1/note/read/:noteId

noteId

/v1/issuer/list

                             

/v1/user/skill/read-userIduserId

How Redis will be used :

Redis is an in-memory data structure project implementing a distributed, in-memory key-value database with optional durability. It will be used to keep API response of the most frequently used and least frequently updated API.
Redis supports primary key, indexing and composite key implementation which will be very beneficial in our use case.

Keys have the TTL functionality. We will set the key expiry time to average time for data being refreshed. Expiry time can be set to different for each key.

For example : Key combination for user read API . userId and singled valued hash for each group (u for User , o  for Org )

Following will the scenario:


  1. Service will get data from Redis and returns the response to controller.
  2. Service will not get data from Redis, now Service will get data from Database , returns it and update Redis cache for the future  :  considering valid data scenario.
  3. Service will not get data from Redis, Now it will try to get it from Database . But For a invalid data it returns the error response.  No Redis cache update. : considering invalid data scenario.



  • No labels