Overview
Use of caching for sending Response for the API which are most used and have least frequency of update of underlying data.
Benefits :
- It will reduce the load on database and also improve response time.
- Will able to keep up all the supported API alive in case of database failure.
Disadvantage :
- 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 ENDPOINT | KEY |
|---|---|
| /v1/user/read/:uid | userId |
| /v2/user/read/:uid | userId |
| /v1/user/getuser | userId |
| /v1/role/read | |
| /v1/user/course/list/:uid | userId |
| /v1/org/read | orgId |
| /v1/page/read/: pageId | pageId |
| /v1/page/section/list | pageId |
/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-userId | userId |
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 a minimum of 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 )