Reading https://www.gooddata.com/developers/cloud-native/doc/1.6/administration/data-sources/notification/ I presume the registerUploadNotification API call does redis cache invalidation across the datasource. 1. Is it possible to invalidate per-workspace, instead of across the whole datasource? Our ETL updates are workspace by workspace, so wiping out the whole organization (/datasource) cache is not optimal 2. Does registerUploadNotification do any pro-active re-calculation? Or is this done on subsequent browser opening a given dashboard? (Docs say "Notification sets up all reports to be computed again with new data.") 3. What's the difference between registerUploadNotification & rebooting redis? (a broad question, trying to get more sense of how caching is used.)

Hi @Carson Gregory, your assumption is correct. The cache is invalidated across the whole datasource. Regarding to your questions: ad 1) We don’t support per-workspace invalidation now. We can consider to add this to our roadmap (cc @Ondrej Macek). Also, we have to validate this use-case if it’s even feasible. ad 2) No, there’s no proactive re-calculation. So as you are stating, the new cache entry is created only when the corresponding dashboard/insight is rendered again. ad 3) Well, this depends mainly on the Redis configuration. If you use the clear in-memory storing, rebooting Redis looses all its data (see all https://redis.io/topics/persistence possibilities). On the other hand, if data are somehow persisted, the only way to invalidate cache is to call

registerUploadNotification

. The main concept of the (datasource) caching and the invalidation is very simple. The notification generates system-wide unique ID which is part of every cache key containing data for the particular datasource. In the case the new notification is received, such keys are then “invalidated” because new system-wide unique ID is used for caching.

Thank you, Peter