3 ms·

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 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-work-under-the-hood https://docs.readyset.io/concepts/overview#how-does-readyset...

zer00eyz 3y ago
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).
- hobofan 3y ago
  > 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.
  - zer00eyz 3y ago
    >> 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...

zer00eyz 3y ago

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

hobofan 3y ago
> 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.
- zer00eyz 3y ago
  >> 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...