/
Cache Implementation Design

Cache Implementation Design

Owned by Manzarul Haque
Last updated: Jul 30, 2018

Overview :

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Ā Cache is an important aspect of an application to improve the api response time. For any heavily used system we need to have aĀ mechanism to cache some of the data , which is not going to change very frequently.Ā 

Ā  As of now Sunbird won't have anyĀ  CachingĀ mechanism on server side. So we are trying to bring caching implementation in Sunbird.Ā  This Document will describe following sections.

Ā  1.Ā  Different ways to do caching

Ā  2. What are the things need to be cache?

Ā  3. what should be ttl?

Ā  4. Cache implementation Design

Different Caching implementation

Ā a.Ā  In memory cacheĀ  :

Ā  Ā  Ā  Ā Pros :Ā 

Ā  Ā  Ā  Ā  Ā  Ā 1. Data lookup is faster because it's storeĀ  in same server in memory.

Ā  Ā  Ā  Ā  Ā  Ā 2.Ā No serialisation / deserialisation overhead

Ā Ā  Ā  Ā  Cons :Ā Ā 

Ā  Ā  Ā  Ā  Ā  Ā  1.Ā  in case of multiple instance data inconsistency will occurs.

Ā  Ā  Ā  Ā  Ā  Ā  2.Ā  Server memory usages will be high

Ā  Ā  Ā  Ā  Ā  Ā  3. Scaling will be problem due to in memory cache.Ā 

Ā b. Distributed Cache :Ā 

Ā Ā  Ā  Pros :Ā  Ā  Ā 

Ā  Ā  Ā  Ā  Ā  Ā  1. Easy to scale

Ā  Ā  Ā  Ā  Ā  Ā  2. No dataĀ  inconsistency

Ā  Ā Ā  Cons :

Ā  Ā  Ā  Ā  Ā  Ā 1. Single point of failure

Ā  Ā  Ā  Ā  Ā  Ā  2. some latency for data read.Ā Ā 

What need to be cache:

Ā We need to cache following api responsesĀ 

Ā  Ā  Ā  Ā  Ā  Ā  Ā 1. get roles

Ā  Ā  Ā  Ā  Ā  Ā  Ā 2. get MediaTypes (Social media link)

Ā  Ā  Ā  Ā  Ā  Ā  Ā 3. get Org Type

Ā  Ā  Ā  Ā  Ā  Ā  Ā 4.Ā  page Assemble

Ā  Ā  Ā  Ā  Ā  Ā  Ā  5. Org Creation report

Ā  Ā  Ā  Ā  Ā  Ā  Ā  6. Org Consumption report

Ā  Ā  Ā  Ā  Ā  Ā  Ā  7. User creation report

Ā  Ā  Ā  Ā  Ā  Ā  Ā  8. User consumption report

Ā  Ā  Ā  Ā  Ā  Ā  Ā  9. Course consumption report

Ā  Ā  Ā  Ā  Ā  Ā  Ā  10. Skills list

Ā  Ā  Ā  Ā  Ā  Ā  Ā  We can add some other user specific api for caching.

Ā  Ā  * TTL can be define based on data changes policy. if Data is going to change once in a while then ttl can be more.

Ā  Ā Ā 

Implementation design with Redis:Ā 

Ā  Ā 


WorkFlow:Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Every request will be received by learner service filter, then filter will verify uri inside Api cache Map. This map will contains all those uri that need to be cached.

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Case 1: Uri found inside map then with help of redis client it will make call to redis server.

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Case 1.1 :Ā  If data found in cache then it will be served from here it self.

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  case 1.2 :Ā Ā If data not found then response will be served from server and same will be saved in cache as well.

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Case 2 :Ā Ā Uri not found inside map then normal flow will work.


Notes:Ā 

Ā  1 .Some of the master data will be loaded during server startup.

Ā  Ā  Ā  Ā  Ā  Ā  Example : Role read, Page section cache,Ā  OrgType , MediType, Skill Lists.

Ā  2.Ā  Update will happen on Cache data as well .Ā  Ā  Ā  Ā 


public interface DataCacheĀ {

Ā  public boolean saveData(String identifier, String value,long ttl);

Ā public String readData (String identifier);

Ā public booleanĀ  updateĀ (String identifier, String value,long ttl);

publicĀ  boolean dataFlush();

Ā }


public Class RedisDataCacheImpl implementsĀ DataCacheĀ  Ā {


}

Different caching framework.

Ā 1. RedisĀ  Ā 2. EhCacheĀ  3. MemCacheĀ  4. HazelCast

Ā Redis :Ā Ā  Redis Read and write performance is more than EhCache , MemCache and HazelCast.

Ā  Ā  Ā Pros :Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Ā 1. Supported multiple data type storage

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  2. Replication (Master salve) or (Master master) possible

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  3.Ā  Data Consistency and durability

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  4. In-memeory support too

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  5.Ā  Support for pub sub model.

Ā  Ā  Ā Cons :Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā 1.Ā  Single threaded.

Ā  Ā  Ā  Ā Ā 

Apart from that server can set Cache-control , EtagĀ  header to do the cache from caller side as well.Ā 

Approach to generate the key:

Ā There are different approach to generate keys.

Ā  Ā 1. Store key as normal StringĀ 

Ā  Ā  Ā  Ā  Ā  Ā  Example:Ā Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā GETĀ  /v1/user/read/{userId}?keys=missingFields,profileCompleteness

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Key can beĀ  :

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  a.Ā  "/v1/user/read/{userId}"Ā Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  b.Ā  "/v1/user/read/{userId}?keys=missingFields,profileCompleteness"

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  c :Ā  {"/v1/user/read/{userId}" :{"keys=missingFields,profileCompleteness":""}Ā }

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  d : Do the hash of complete key

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  POST/PUT/PATCHĀ  Ā /data/page/assember

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā "request":{
Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā "source":"web",
Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  "name":"Explore_test",
Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā "filters":{
Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā }
Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā }

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Key can be :Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā HashOfĀ  (URI+RequestBody):

Note:Ā 

Ā  Ā 1. Need to think about data privacy.Ā 

Ā  Ā 2. Key generation need to be explore more.

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā 


Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Ā 

Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā  Ā Ā 


Related content