Hacker News Reader

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).

View on HN

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