3 ms·
Not listed: temporal locality. A lot of naive caches inflate in size to satisfy a high hit ratio but end up with low accesses per item. Etsy's mctop is useful h
by greenleafjacob 10y ago
Not listed: temporal locality. A lot of naive caches inflate in size to satisfy a high hit ratio but end up with low accesses per item. Etsy's mctop is useful here although not possible if you're using e.g. Elasticache.
Not listed: persistent caches. A friend of mine ran a cache for a CDN. Their caching solution mushroomed in complexity to satisfy the legal obligation of taking down illegal content because their cache persisted to disk, so when servers came back up from maintenance they had to check in with a master revocation list. This made operations somewhat complicated because the system was failsafe - an old server would refuse to startup if it detected that it was older than the size of the revocation list (a 1 week KAFKA queue). Lots of horror stories about zombie resurrected content being served before this was implemented.
Somewhat alluded to: over reliance on cache. My former job on a high traffic website was behind a fantastically fast high hit rate cache for almost the entire site, necessary for the scale they were operating at. The trouble was the cache shielded the system from so many requests it became a single point of failure, so if the cache was flushed then the system would become quickly overloaded and wouldn't recover the hit rate for an hour or so. We had to invest a lot of time and energy in cache replication systems, consistent hashing, and related systems - mostly careful choice of existing systems. Shoutout to mcrouter by Facebook.