3 ms·
Interestingly enough, in my entire career so far, for things that weren't cached that should have been or were already cached and working, the one invalidation
by bkuehl 6y ago
Interestingly enough, in my entire career so far, for things that weren't cached that should have been or were already cached and working, the one invalidation point was the save page of the entity. Sometimes it's not that hard for vast majority of cases.
- ramraj07 6y agoIndeed. I’m not even sure the post was talking about cache invalidation, more like what is the correct abstraction by which you cache something. I only truly understood cache invalidation problems when I read Instagram’s engineering posts - then it dawned on me how hard it is for them to maintain a cached user profile database that has to spread over the entire world for a billion users (and potentially constantly be invalidated as users from around the world like their post etc).
- redis_mlc 6y ago> Sometimes it's not that hard for vast majority of cases. That is correct based on practical experience. Developers who ignore the prevailing wisdom about caching invalidation and edge case problems and "just do it", with even multi-level caches, are finding they work better than expected. The only blanket exception is "don't do that if you're a bank and it's money", but otherwise it works out. I'm doing some fancy things with Redis, and I just keep the TTLs to about a minute and it's all good. With a short TTL, often you don't even need to update the cache on the save page.