Hacker News Reader

Comment by PaulHoule | Hacker News Reader

This is an aphorism I got tired of a long time ago.

There was a batch job that I sped up about 40 times with a cache. The invalidation strategy I used was "dump the whole cache and start a new one" which wasn't too bad because the system got about 10% through the job when it ran out of RAM and it had a pattern of a long-tail distribution plus locality which fit that model well.

If I'd been memory-constrained, or had a distributed system, it would have been a different story, but it's not unusual for caching to be a win with a simple invalidation strategy.

View on HN

To be fair, rocket science is also hard, but not very much when all you plan to do is hitting a barn door with fireworks. Same with prime factorization when the number to factor is “15”, spontaneously sketching out the pole-zero diagram of f(x)=0… you get the gist.

Usually when people talk about a topic being hard, they don’t mean the very constrained cases that are easy.

It's the other way around.

90% of the cases are easy cases, where thinking too hard about invalidation (as opposed to testing what works) is likely to give you worse performance.

There are a rare set of cases that are devilishly hard such as synchronizing the caches across an SMP microprocessor or making a system like Cloudflare really speed up your web site as opposed to slowing it down.

When it comes to cache invalidation worse performance isn’t the primary concern in most cases, correctness is.

> 90% of the cases are easy cases

I'll second this. For example, I can usually get away with simple and short lived TTL caches in varnish (with grace) for high traffic read only APIs. Flushing (invalidation) is automated since it just expires. It doesn't always fit, but often it does.

It’s amusing because rocket science is pretty easy. Rocket mechanics is the tricky part.

Rocket scientists can be heard saying "It's not like it's cache invalidation!".

Reply on news.ycombinator.com