←back to thread

Caching is an abstraction, not an optimization

(buttondown.com)
134 points samuel246 | 1 comments | 01 Jul 25 10:42 UTC | HN request time: 0.201s | 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. williamdclt ◴[03 Jul 25 22:21 UTC] No.44459632[source]▶
You don’t support read-your-own-write and your cache data might be stale for arbitrarily long. These relaxed consistency constraints make caching a lot easier. If that’s acceptable to your use cases then you’re in a great place! If not… well, at scale you often need to find a way for it to be acceptable anyway