Loading...
1)Store /update the data with unique key
2)retrieve the record based on key.
3) create cache invalidation based on TTL.
4)Users should be authenticated
1) High available : System should be highly available
2) Scalability : System should be scalable when the number of user load increase.
3 Consistency : Maintain consistency with the original data source
Average sizes: Html page =50KB,Image = 100kb,video = 2mb
cache : Html page =10,000,Images :20,000,Images : 1000
Total Size = 50kb*100000+100kb*20000+2Mb*1000 = 9*10^9= 9GB
1) To create/Insert the cache :
POST /api/v1/put
parmeter : Key : Integer
Value:String
return 201 created
2) To view the cache
Get /api/vi/get/{key}
return Value as an string
1)
For both the request either to put OR get the value from cache it flows through Load balancer to webserver and first cache client fetch which server the cache are stored using configuration server (zookeeper/etcd).
2) the cache are sored in the consistent hashring with leader and read replica for better performance.
1) We have portioned the record based on key and used consistent hashing to make sure that the portioned records are not skewed .
2) We have used configuration server to know that which server based on key need to redirect the cache clients.
3) We have opted Leader and replica model to provide high availability of the system
1) We have choose the zookeeper/etcd for configuration manager to mange the cache client to redirect to correct node based on key.
2)there can be issue when there is any particular key has higher load and to over come with that we can have virtual nodes created to handle larger traffic.
3) we are using consses algorithm to make the higher consistency .
1) We can have read replicas in case of leader fails any of the read replica will become the leader.
2)Strong consistency can be tuned based on the use case and we are using concesse algo which relay on (R+w)>n gives strong consistency.
1) we can use API gateway for rate limiting and to handle authorization of the application.