News for hackers. Stuff that matters.
Re:How not to structure database-backed web apps: performanc... by snowwrestler on Thursday June 28, 2018 @01:55PM (#17419057)
True but cache invalidation is famously hard to get perfect.

A nicer way to put it might be that finite TTLs should be viewed as an opportunity to optimize, not ideal or standard.

Re:How not to structure database-backed web apps: performanc... by mklepaczewski on Thursday June 28, 2018 @02:23PM (#17419272)
True, caching even simple data dependant on 2-3 variables may require writing dozens of test cases - in practice, it often turns out that the data doesn't rely on 2-3 but 5-10+ variables.

However, just because it's hard it doesn't mean we shouldn't do it the right way.

Re:How not to structure database-backed web apps: performanc... by jungturk on Thursday June 28, 2018 @02:58PM (#17419529)
Of course it does - negotiating trade-offs and accepting the set that best achieves your objectives is a large part of software design (and also undermines the notion of doing things a "right way").

Wouldn't deploying a less-than-precise TTLs be an appropriate trade-off for non-transactional caches, caches subject to network partitions, caches that can't enroll in invalidation messages, caches that can't poll for change sets, caches that can't implement eviction policy, etc?

Certainly the cache should be transparent about the trade-offs it has made (such as not promising authoritative data if it's accepting eventual consistency via TTL).