Ideation on a query call enabled stable storage cache

So I’ve found the need for maintaining some sort of cache written from query requests. This would allow computation derived in query calls to be leveraged for future query calls, while still not requiring full consensus, at least to provide the caller with a response. This would involve adding some sort of dedicated, single page of stable storage. The page would only persist for limited time, some options could include a ttl, a manual wipe using the sdk, or simply for the duration of the canister state, that is, the cache is wiped upon any state change/update. The process would happen with a modified stable storage write, that has the same functionality as regular stable store, but the subnet would handle the query as a special case if used. Basically, how I see it happening, is the subnet would execute the query as regular, respond to the request, and afterwards process the request again, with full consensus across the subnet, and allow a write to the stable storage, and nothing else, for the now verified cache data.

Let me know your thoughts on the subject!

1 Like