System requirements

Functional:

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

Non-Functional:

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

Capacity estimation

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

API design

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

Database design

1)

High-level design

Request flows

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.

Detailed component design

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

Trade offs/Tech choices

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 .

Failure scenarios/bottlenecks

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.

Future improvements

1) we can use API gateway for rate limiting and to handle authorization of the application.