4 ms·

This would have been a really good article in itself, without the frankly unbelievable hubris of the author. TL;DR this is a blogpost about some very interesti

This would have been a really good article in itself, without the frankly unbelievable hubris of the author. TL;DR this is a blogpost about some very interesting problems with distributed cache consistency and observability. The article doesn't address cache invalidation and - based on their replies here - the author doesn't seem to understand the cache invalidation problem at all.

uvdn7 4y ago
I am glad that you liked the content. On the definition of cache invalidation, and specifically why it's hard. Can you send me a link to any definition of it? This is what's in wikipedia and I think it's reasonable. > Cache invalidation is a process in a computer system whereby entries in a cache are replaced or removed. And I think I am describing that process, and what's hard about it. Some comments here explicitly talk about dependencies, which I can see why it's hard. My point is that even without dependencies, cache invalidation remains a hard problem. Now about dependency tracking, some of my thoughts are captured here https://news.ycombinator.com/item?id=31674933 https://news.ycombinator.com/item?id=31674933.
- lucideer 4y ago
  Numerous replies to your comments here have pointed out why cache invalidation is hard. You've responded to them by saying "Good point!" (always with an exclamation point), and then proceeded to demonstrate in your response that you didn't understand their point. This comment describes the "hard" part of cache invalidation best: https://news.ycombinator.com/item?id=31674251 https://news.ycombinator.com/item?id=31674251 - your response to them makes very little sense. First, you acknowledge that they're correct, though you use obtuse language to say so: you seem to like using the very abstract term "dependency" to represent the very simple concept of detecting updates. In your second paragraph you then go off on an unrelated tangent by saying: > Now getting back to the “what’s really hard about cache invalidation” part. No. You're not "getting back" to that - you're changing the subject back to the topic of your article, which is unrelated to cache invalidation. > Say you just have a k/v store, no joins, nothing. Cache invalidation is about invalidation - it's not about your store architecture. It's not about the implementation of logic that processes the clearing/overwrite of values, it's about the when and nothing else. > just doing TTL, would be simpler. Yes. It is simpler. If you want to avoid solving the hard problem, you can use a TTL. Now... how long should it be?
  - uvdn7 4y ago
    First of all, I do think you folks make good points. Let me try again. > The invariant is that as long as the "context/filter" you encode covers all the mutations which would impact your cache data, you should be good. I wrote this line, which is referred to as that being exactly why cache invalidation is hard, in the commented you linked. > it's about the when and nothing else. Let's talk about that. Not to over generalize this, with a simpler cache model (say you just cache a single item), do you agree that solving the "when" problem is very managable? If not, I would like to be enlightened. Now with this very simple cache model, where we have "magically" solved the "when" problem. Do you think cache invalidation is solved? Or it's simple? After knowing when, you still need to actually update cache right, and not to leave it in an inconsistent state (against the source of truth). Is that simple? Let's essentially break cache invalidation into a few parts 1. knowing when/who to invalidate 2. actually processing the invalidate My argument is that #1 can be very managable with simpler data models. #2 can't be avoided; and #2 is very hard.
    - lucideer 4y ago
      > with a simpler cache model (say you just cache a single item), do you agree that solving the "when" problem is very managable? The "when" problem is dependent on your application architecture, not on your cache backend nor the number of keys in it. If, overall, you have an extremely simplistic application architecture, then cache invalidation may be quite easy, but you'll either: 1. forgo advanced user interaction or dynamic updates, in which case cache invalidation may not even be required at all (excepting publishing) 2. have scalability problems, and need to increase the complexity of your application to meet those challenges The difficulty of cache invalidation scales with the complexity of your application (and not necessarily linear scaling) > My argument is that #1 can be very managable with simpler data models. #2 can't be avoided; and #2 is very hard. Yes, #1 can be manageable for low-traffic simple static applications. It is a general problem who's difficulty relates to the complexity of the application. Yes, #2, can't be avoided. But, while it is interesting, and - in some cases, given a specific caching stack - it may be relatively hard, it's not a general problem. Difficulties with it are implementation-specific, not broadly applicable. Significantly, it's not the general and fundamental hard problem being referred when people talk about the universal difficulty of "cache invalidation".
deleted 4y ago
[deleted]

uvdn7 4y ago

I am glad that you liked the content. On the definition of cache invalidation, and specifically why it's hard. Can you send me a link to any definition of it? This is what's in wikipedia and I think it's reasonable. > Cache invalidation is a process in a computer system whereby entries in a cache are replaced or removed. And I think I am describing that process, and what's hard about it. Some comments here explicitly talk about dependencies, which I can see why it's hard. My point is that even without dependencies, cache invalidation remains a hard problem. Now about dependency tracking, some of my thoughts are captured here https://news.ycombinator.com/item?id=31674933 https://news.ycombinator.com/item?id=31674933.

lucideer 4y ago
Numerous replies to your comments here have pointed out why cache invalidation is hard. You've responded to them by saying "Good point!" (always with an exclamation point), and then proceeded to demonstrate in your response that you didn't understand their point. This comment describes the "hard" part of cache invalidation best: https://news.ycombinator.com/item?id=31674251 https://news.ycombinator.com/item?id=31674251 - your response to them makes very little sense. First, you acknowledge that they're correct, though you use obtuse language to say so: you seem to like using the very abstract term "dependency" to represent the very simple concept of detecting updates. In your second paragraph you then go off on an unrelated tangent by saying: > Now getting back to the “what’s really hard about cache invalidation” part. No. You're not "getting back" to that - you're changing the subject back to the topic of your article, which is unrelated to cache invalidation. > Say you just have a k/v store, no joins, nothing. Cache invalidation is about invalidation - it's not about your store architecture. It's not about the implementation of logic that processes the clearing/overwrite of values, it's about the when and nothing else. > just doing TTL, would be simpler. Yes. It is simpler. If you want to avoid solving the hard problem, you can use a TTL. Now... how long should it be?
- uvdn7 4y ago
  First of all, I do think you folks make good points. Let me try again. > The invariant is that as long as the "context/filter" you encode covers all the mutations which would impact your cache data, you should be good. I wrote this line, which is referred to as that being exactly why cache invalidation is hard, in the commented you linked. > it's about the when and nothing else. Let's talk about that. Not to over generalize this, with a simpler cache model (say you just cache a single item), do you agree that solving the "when" problem is very managable? If not, I would like to be enlightened. Now with this very simple cache model, where we have "magically" solved the "when" problem. Do you think cache invalidation is solved? Or it's simple? After knowing when, you still need to actually update cache right, and not to leave it in an inconsistent state (against the source of truth). Is that simple? Let's essentially break cache invalidation into a few parts 1. knowing when/who to invalidate 2. actually processing the invalidate My argument is that #1 can be very managable with simpler data models. #2 can't be avoided; and #2 is very hard.
  - lucideer 4y ago
    > with a simpler cache model (say you just cache a single item), do you agree that solving the "when" problem is very managable? The "when" problem is dependent on your application architecture, not on your cache backend nor the number of keys in it. If, overall, you have an extremely simplistic application architecture, then cache invalidation may be quite easy, but you'll either: 1. forgo advanced user interaction or dynamic updates, in which case cache invalidation may not even be required at all (excepting publishing) 2. have scalability problems, and need to increase the complexity of your application to meet those challenges The difficulty of cache invalidation scales with the complexity of your application (and not necessarily linear scaling) > My argument is that #1 can be very managable with simpler data models. #2 can't be avoided; and #2 is very hard. Yes, #1 can be manageable for low-traffic simple static applications. It is a general problem who's difficulty relates to the complexity of the application. Yes, #2, can't be avoided. But, while it is interesting, and - in some cases, given a specific caching stack - it may be relatively hard, it's not a general problem. Difficulties with it are implementation-specific, not broadly applicable. Significantly, it's not the general and fundamental hard problem being referred when people talk about the universal difficulty of "cache invalidation".

deleted 4y ago

[deleted]