Hacker News Reader

I could see this being very useful. The standard cache + db architecture has some sharp edges that end up biting people all of the time e.g. the thundering herd problem.

View on HN

Not only that but your database and app are working under the assumption of Read Committed or better and now by introducing a cache that is out of band from your database transactions you’re introducing a whole slew of consistency bugs (that often go undetected).

I may be missing the point here, but isn't it common to address this through a combination of timestamped keys[1] and interleaving database and redis transactions (start redis transaction, start db transaction, update db and add cache operations to current trx, and finally commit db trx and if it succeeds commit the redis trx, otherwise rollback the redis trx.)

[1] https://blogcabin.37signals.com/posts/3113-how-key-based-cac...

Is the interleaving of redis and db transactions atomic?

Not technically, but you are guaranteed that if the db transaction fails, we don't end up with invalid data in redis.

The other side is not true though, but that will just cause a cache miss if the keys are timestamped.

Reply on news.ycombinator.com