←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: 0.446s | 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. hmottestad ◴[03 Jul 25 22:01 UTC] No.44459529[source]▶
Does SQS guarantee delivery to all clients? If it does then that’s doing a lot of heavy lifting for you.

If it doesn’t guarantee delivery, then I believe you will at some point have a client that reads a cached value thinking it’s still valid because the invalidation message got lost in the network.

replies(1): >>44459789 #
2. maccard ◴[03 Jul 25 22:54 UTC] No.44459789[source]▶
Eventually. The problem is that eventually delivering that message will result in clients assuming that it will always be the same, when it’s not.