3 ms·

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

• rubiquity 5y ago
  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).
  • lf-non 5y ago
    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-cache-expiration-works https://blogcabin.37signals.com/posts/3113-how-key-based-cac...
    • Orou 5y ago
      Is the interleaving of redis and db transactions atomic?
      • lf-non 5y ago
        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.