←back to thread

Caching is an abstraction, not an optimization

(buttondown.com)
134 points samuel246 | 2 comments | 01 Jul 25 10:42 UTC | HN request time: 0s | source
Show context
ckdot2 ◴[03 Jul 25 19:03 UTC] No.44458190[source]▶
"I think now caching is probably best understood as a tool for making software simpler" - that's cute. Caching might be beneficial for many cases, but if it doesn't do one thing then this is simplifying software. There's that famous quote "There are only two hard things in Computer Science: cache invalidation and naming things.", and, sure, it's a bit ironical, but there's some truth in there.
replies(11): >>44458265 #>>44458365 #>>44458502 #>>44459091 #>>44459123 #>>44459372 #>>44459490 #>>44459654 #>>44459905 #>>44460039 #>>44460321 #
Traubenfuchs ◴[03 Jul 25 21:31 UTC] No.44459372[source]▶
I never understood this meme.

We use caching a lot, anything that gets cached can only be written by one service each. The writing services emit cache invalidation messages via SNS that cache users must listen to via SQS, to clear/update their cache.

Alternatively we cache stuff with just a TTL, when immediate cache invalidation is not important.

Where‘s the struggle?

replies(8): >>44459400 #>>44459529 #>>44459632 #>>44459774 #>>44461198 #>>44463192 #>>44464161 #>>44465957 #
1. graealex ◴[04 Jul 25 10:25 UTC] No.44463192[source]▶
That's because relying on a TTL simplifies the concept of caching, and makes invalidation trivial, and also inflexible.

It's used in DNS, which already was an example here. There is no way to be sure clients see an updated value before end of TTL. As a result, you have to use very conservative TTLs. It's very inefficient.

replies(1): >>44467115 #
2. ahoka ◴[04 Jul 25 19:15 UTC] No.44467115[source]▶
You can’t be sure even after the TTL to be fair.