it can be solved using same scenario as mentioned in first article .
Suppose there are 12 Million of users are adding every year meaning 1 Million per month.
So if we consider 5 year there will be around 60 million of users. Now in terms of data we can look to our DB table and get information about it. A user will be generally having name , id , address , some forien keys .
Lets assume 10 columns with each column on an average storing 4 byte of data.
10*4 = 40 bytes of data for one user.
60 * 10^6 * 40 = 2400 * 10^6 = 2.4 * 10^9 = 2.4 GB of data we need to store only user values.
Also while calculating storage for the user there is also one important point we need to remember is of ids. If we are going to have 60 Million of users which means 60*10^6 users so unique id’s will be
as we know below figures are almost equal
then 60*(10^3)^2 = 2^20 *2^6
which means we almost need 26 bits for storing ids. If we have any separate system to generate these ids then 26*60*10^6=1560*10^6=1.5 GB approx.
Cache storage :-
calcluting an idea for cache storage is not tough once we have an idea of calculating total storage . Cache normally sits between end user and application servers and caters read requests for the website. Nearly 60-80 percent of users do not apply any modification to the data of website and just read data. To avoid load on application servers which are modifying data for write requests and involve in lot of performance on data we use cache servers which just caters data as a replica of original one. So if we have 500 GB of original data , 100 GB of data can be served through cache.
There can be multiple techniques we can use for cache such as LRU , LFU which i will explain in coming articles.