> Yeah, the article was like "I always need a DB anyway" but then sets up an extra cronjob to expire keys, plus more code.

You do not need cron jobs to do cache. Sometimes you don't even need a TTL. All you need is a way to save data in a way that is easy and cheaper to retrieve. I feel these comments just misinterpret what a cache is by confusing it with what some specific implementation does. Perhaps that's why we see expensive and convoluted strategies using Redis and the like when they are absolutely not needed at all.

▲

maxbond 10 hours ago | parent [-]

If we don't use a TTL, aren't we going to have to either accept that our cache will grow without bounds or take an even more sophisticated approach (like tracking access times instead of creation times)? Is there something simpler I'm not seeing?

▲

motorest 10 hours ago | parent | next [-]

> If we don't use a TTL, aren't we going to have to either accept that our cache will grow without bounds (...)

Do you have a bound? I mean, with Redis you do, but that's primarily a cost-driven bound.

Nevertheless, I think you're confusing the point of a TTL. TTLs are not used to limit how much data you cache. The whole point of a TTL is to be able to tell whether a cache entry is still fresh or it is stale and must be revalidated. Just because some cache strategies use TTL to determine what entry they should evict, that is just a scenario that takes place when memory is at full capacity.

▲

maxbond 9 hours ago | parent [-]

A TTL doesn't really tell you if it's stale though. It gives you an upper bound on how long it can have been stale. But something becomes stale when the underlying resource is written to, which can happen an hour or an instant after you cache it. You should probably evict it when the write comes in. In my mind, it's for evicting things that aren't in use (to free up memory).

▲

motorest 9 hours ago | parent [-]

> A TTL doesn't really tell you if it's stale though (...)

Non-sequitur,and imaterial to the discussion.

> You should probably evict it when the write comes in.

No. This is only required if memory is maxed out and there is no more room to cache your entry. Otherwise you are risking cache misses by evicting entries that are still relatively hot.

	▲	frollogaston 8 hours ago \| parent \| next [-]
		The cache isn't the only hot thing here. Relax.
	▲	maxbond 8 hours ago \| parent \| prev [-]
		> Non-sequitur,and imaterial to the discussion. You said: > The whole point of a TTL is to be able to tell whether a cache entry is still fresh or it is stale and must be revalidated. So I responded to it. I don't really understand why you think that's nonsequiter. > No. I'm a bit confused. We're not using TTLs and we're not evicting things when they become invalid. What is your suggestion?

▲

frollogaston 10 hours ago | parent | prev [-]

I've tried it this way. You can get away with no TTL if your keys are constrained. Sometimes there are enough keys to be a problem. I'd rather just set up a TTL and not worry about this.

	▲	maxbond 9 hours ago \| parent [-]
		Agreed, simple and widely applicable heuristics are great, and you can think deeply on it when and if it proves to be an issue worthy of such attention.