Caching Tips

Caching is hard. There's a lot of options and a lot of pitfalls. Below are a few tips to help out.

Data standards for Caching

Not all data is worth caching. Only data that is relatively stable is desirable. If cached data is of the sort that changes frequently it can cause issues where the user finds themselves processing data that is stale. A good example of relatively stable, infrequent updates would be a set of data that only updates at midnight each day. There is a set time for the update, so a caching system can be created with that in mind. 

Not every field associated with a data record needs to be cached. For instance in a ticketing system the ticket id number may never change and that field could be cached, but comments on the ticket or escalation status that could change often should not be cached.

Caching also has practical size limits. Millions of data points should not be cached. 

Cached data should be specific, targeted to a goal, and stable.

Enable Caching

Make sure that Enable Caching is checked. Data will not cache unless this is enabled. 

Decisions Caching Architecture

The Decisions cache is delinked from the outside database. Changes to the database will not reflect in cache until the cache has expired and is refreshed whether from a timer or a Flow. For diagrams see Caching Architecture.

Cache Keys

Keys can be any unique thing. However, it is important to keep in mind that cache keys must be unique. Any data with duplicate cache keys will  be overwritten by the most recent data.