Sometimes, you have to deal with closed-source and legacy software for which there is no sufficient support in the application. This proxy can help boost the performance of such applications.

You are reading from "fresh" (though only eventually consistent) data. For many public facing queries that's enough.

After an initial query seen by their proxy, you can configure all future queries of the same kind to be pre-computed.

So I think it makes more sense to think of it like an auto-updating materialized view available with the click of a button rather than a cache.

There are some more under-the hood details here: https://docs.readyset.io/concepts/overview#how-does-readyset...

Normal request: Request -> work -> work.. -> query/db

Efective Cache: Request -> (less)work -> cache

This Product: Request -> work -> work.. -> query/cache

I understand the concept of caching at a boundary layer. I fail to see the point of cache at THIS boundary layer. You have all the problems of a cache with fewer benefits (you're not going to fix a thundering Hurd at this level).

> You have all the problems of a cache with fewer benefits

No you don't. You have next to none of the problems of a cache (especially as you directly have to opt-in individual queries to it) like cache invalidation, etc., with all the benefits. It's about as free as performance benefits can be (from a implementations standpoint).

I understand that for many use-cases caching at the response level may be preferable, but there are also many use-cases that are read-heavy but also involve a lot of computed values that are updated and have to be recomputed regularly, where this dataflow-based approach has been shown to be one of the least compute intensive and efficient solutions.

>> I understand that for many use-cases caching at the response level may be preferable

Yes after all the data + work/compute

>> there are also many use-cases that are read-heavy but also involve a lot of computed values that are updated and have to be recomputed regularly, where this dataflow-based approach has been shown to be one of the least compute intensive and efficient solutions.

From a comp sci, from a programing, from an engineering perspective I get this. But at the end of the day those are just the hammers and nails of the business. I am wondering where the actual, in production use case, with business need requires this. I can think of a dozen technical fuck ups where this solution is appealing but that's just stacking irresponsibly...

How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?

Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.

That’s how ReadySet works, I’m asking the grandparent (rhetorically) how their own method of caching works for them

What if it's a backend service that is not exposed to a frontend that receives html or Json. E.g a task that takes an id and a operation name and needs to fetch from the database a bunch of data to process.

You will add readyset between your backend and database in order to cache the data you fetch from db.

I'm answering the comment above mine that is asking for a user case. I'm saying that my use case is an example where json/html caching is not sufficient. 100% agree with you.

Ever add (or inherit) the server-side part of an application that uses Redis or Memcache? The data is denormalized: When you do an update/insert/delete into the SQL side of things, you need to do a corresponding change in Redis / Memcache. All of your queries end up being something like: Try Redis/Memcache, if the data isn't present, query the database and insert into Redis/Memcache.

It (Redis/Memcache caching) adds a huge amount of complexity to your application, and the risk of defects is very, very real.

ReadySet basically gives you a magic "stick this thing between your database and application and we'll do the caching for you." It totally eliminates a time consuming and error-prone part of your application.

If you want to, they go into details here: https://blog.readyset.io/dont-use-kv-stores/