Didn’t we made mistake when calculating the needed memory cache? How can we cache incoming requests and not created data? shouldn’t we cache 20% of new URLs to look them up in the cache before in the database when the request comes? how can we even cache incoming requests…??
B.
I don’t have a software background but i agree with you. the cache should be based on the created data which will be 1.7GB per day. They can technically cache 100%.
The purpose of cache is making read response faster.
So cache the data which is getting request hit, not the data which was recently created but the most recent reads.
I think the author is trying to say is we should cache the data that is got the hit is last 24 hours is likely to be hit again in some time.
I hope my answer will help.
I think in this case pushing the created data make sense since there is high chance of using this shorten link often … Since this is read heavy service putting in advance with some TTL for each key as shorten url is better … so that whatever key that is not being used for long time will automatically expire and can fallback on Persistence store db and write it back for next cache hit.
Firstly, new URL shortenings requests per second and total redirection requests per second have no relation. They are two different statistical points.
100:1 ratio is just a mere assumption, and does not form any logical relation between new URL shortenings requests per second and total redirection requests per second.
So coming to the point, for example if we assume there are 50 redirection requests per day. 80-20 rule suggests that there are approx.10 distinct tiny URLs which are responsible for approx. 40 redirection requests per day. That’s why we have to cache 20% of the total requests per day. These 10 distinct tiny URLs can be old ones or new ones. These 10 tiny URLs have no relation to newly created tiny URLs.