3 ms·
Remind me again why I would want to pull consistency guarantees out of an actual datastore (which is designed to provide those guarantees) and force-fit that pr
by shermantanktop 2y ago
Remind me again why I would want to pull consistency guarantees out of an actual datastore (which is designed to provide those guarantees) and force-fit that problem into a fancy caching layer?
The Kleppman critique about efficiency vs correctness is exactly right. Redis for efficiency is great as a work-saving optimization. Redis for correctness (assuming it is possible) asks a remote system to enforce behavior at a far remove from the place where correctness is evident, which is system state, usually data in a datastore.
- singron 2y agoIf you can model your mutation as a database transaction, then that's probably the best. In the past, we've wanted these kinds of solutions when performing actions that weren't in a transactional database. E.g. third party APIs, multiple databases, non-transactional databases, work assignments, rolling restarts and other risky control plane changes. Also a lot of databases can degrade performance when transactions are held open (e.g. in postgres, an open transaction will prevent the cleanup of dead tuples across all tables, which can cause pathological slowdowns in certain workloads), so you might want to move long-held locks out of your database.
- shermantanktop 2y agoOh absolutely. I have a horror story about Hibernate and annotations taking a lock while listing objects in S3. Someone added a million objects to the bucket and…bad things ensued.
- sriram_malhar 2y agoDepends on the consistency guarantee and workload. If it is just linearizability (atomic key-value storage) then write-through caches work simply and correctly. You reap the benefits on the read side.