2 ms·

Yes. One danger of infrequently-invalidated or never-invalidated data is that it can turn into a ticking time bomb. For example you may introduce a bug in the

by borplk 6y ago

Yes. One danger of infrequently-invalidated or never-invalidated data is that it can turn into a ticking time bomb. For example you may introduce a bug in the code path for calculating the fresh value that causes an error. That code may not execute for months and months since the cache is warm and up and running. Until one day it is restarted and you find out the problems it was masking. Pro tip: don't get greedy with cache TTL, define and enforce a low value that you can tolerate. In many use cases you can easily afford to re-compute once per 5 or 10 or 30 minutes.

WrtCdEvrydy 6y ago
We've given up on this whole idea and basically gone for extremely long TTLs (30 days) on our caching layer. We then built the tooling to dump caches after deploys and manually on request. You can dump caches at the application layer, or even down to the specific request param combination layer. It's worth investing a bit into systems.
- jrochkind1 6y ago
  I have seen systems that use caching so heavily that when the cache is invalidated en masse, they need to bring up extra compute resources to fill it again, because the system under normal load with an empty cache needs so many more resources. Basically the system can no longer function adequately with a cold cache. This is of course a pain to orchestrate. I suppose regularly clearing out the cache is a way to be sure you aren't in that situation, or at least know it when you become so. My experience with those systems is one reason that I'm reluctant to take the position of resorting to caching before trying to optimize the underlying code. It makes me want to treat caching as a last resort when I can't feasibly (whether due to time or skill or actual external limits) optimize any further, which is I think a bit different than the attitude OP is suggesting. The maintenance "cost" of adding a cache layer is in my experience higher than the OP suggests. Failure-to-invalidate/stale cache bugs can be very easy to make and difficult to debug and solve when using a strategy that depends upon invalidation, like 2 and 3 in the OP.

by borplk 6y ago

WrtCdEvrydy 6y ago

We've given up on this whole idea and basically gone for extremely long TTLs (30 days) on our caching layer. We then built the tooling to dump caches after deploys and manually on request. You can dump caches at the application layer, or even down to the specific request param combination layer. It's worth investing a bit into systems.

jrochkind1 6y ago
I have seen systems that use caching so heavily that when the cache is invalidated en masse, they need to bring up extra compute resources to fill it again, because the system under normal load with an empty cache needs so many more resources. Basically the system can no longer function adequately with a cold cache. This is of course a pain to orchestrate. I suppose regularly clearing out the cache is a way to be sure you aren't in that situation, or at least know it when you become so. My experience with those systems is one reason that I'm reluctant to take the position of resorting to caching before trying to optimize the underlying code. It makes me want to treat caching as a last resort when I can't feasibly (whether due to time or skill or actual external limits) optimize any further, which is I think a bit different than the attitude OP is suggesting. The maintenance "cost" of adding a cache layer is in my experience higher than the OP suggests. Failure-to-invalidate/stale cache bugs can be very easy to make and difficult to debug and solve when using a strategy that depends upon invalidation, like 2 and 3 in the OP.