Deep dive in to Platform cache

Audience: Advanced Developers

Keywords: Platform cache, session, org cache, custom settings

Please be advised that this post is going to be long and divided in two parts, part 1 covers the theory and in part 2, you can see platform cache in action.

Here it goes,

We know that Salesforce is a multitenant environment, therefore the development team keeps coming up with new ideas to access the data and make application usage faster. In the application life-cycle, the maximum time is taken by the server requests for data fetching, and Platform cache (PC) is yet another way of accessing some frequently used data at minimum resource expense. Platform cache is the temporary storage via which the cached data can be accessed without any SOQL or server calls and is readily available for use.  Or in other words, it is a performance optimization technique to retrieve the same data that is required multiple times during a session, process or org. We will go deeper into the advantages but before let’s get some fundamentals clear regarding why platform cache is better than other data fetching option such as Custom Settings.

Difference between Platform cache and custom settings

If you are aware of custom settings (CS), you would be asking yourself as custom settings data is also cached, so what makes PC so good and why? Though CS is obsolete and is being replaced by custom metadata types, it is still important to know the fundamental difference between CS and PC.

PC and CS, both mean to access data faster but they store entirely different kind of data. CS can cache very specific simple and basic types of data. Where as PC stores complex data types like session information, collections, custom classes and much more. The PC can also handle transformed information from multiple sObjects into a collection, let’s say a map and is accessible as a cache key value throughout the session. And hence the next time such transformation is required, it is directly available via the platform cache, resulting in faster access and saving all the server-side calculations (CPU + SOQL time).

Another reason is the amount if data that can be cached in PC is much more than CS. As PC can handle collections, it can carry multiple records whereas CS can only fetch a single record at a time.

One should consider here that unlike CS, which is indefinite, PC can lose information due to several factors like cache limitations and other apps needing the space, time out or the data is not refreshed over the time. Hence, only the easily reconstruct-able data should be used for PC, so that if there is a cache miss, the data can easily be retrieved from the server.  

The platform cache is accessible in two ways:

  1. Session Cache:

This cache lives per user session and stores information respective to the user such as all the accounts address location in the user’s region.

  1. Organization or Org cache:

This cache is accessible to all the users of the organization i.e. across the user sessions. Here, we can store information that is globally and frequently required, for example, conversion rates for the day. We want to calculate them once and render it across all the users for the day. Such information can be stored in the org wide cache and the users can directly access the conversion rates from this org wide cache variable instead of calling server for the conversion rate. This is also an advantage over CS where the content is fixed until unless change. And conversion rates are dynamic, so I don’t need to maintain the CS every day, instead I make one http call to my authorized conversion rate API and get the rates of the day, store them in the org wide cache.

So, the best type of data that should be stored in cache is,

  1. Data that is to be reused throughout a session
  2. Not rapidly changing data
  3. Data that requires lot of CPU resources to retrieve/transform the data

I will not go deep into the setup details as this trailhead is comprehensive enough to learn about Platform Cache setup, but I will highlight important points here. 

First, you need to enable the platform cache in your org. Platform cache is maintained via partitions. Using partition, once can allocate cache between different applications of the org and make sure that cached data by one app is not overwritten by other apps.

To create the org partition, go to

Setup > Quick Find ‘Platform Cache’ > Click on ‘New Platform Cache partition’.

In the above screenshot, the name of our partition is ‘testCache’.

Put Data into the Key

When we wish to put data into this key, we use the Cache class. Accessing the cache key needs a proper format: Namespace.PartitionName.KeyName

Local is the default namespace of your org. Let’s say we want to create an org cache key named ‘hasCurrencyCodes’, it will be,

Cache.Org.put(local.testCache.hasCurrencyCode, true);

If while creating the partition, we mark the partition as default then we don’t need to provide the namespace qualifier and the key can be directly accessed with the key name, for example

Hence,  below two statements work the same way:

Cache.Org.put(‘local.testCache.hasCurrencyCode’, true)
Cache.Org.put(‘hasCurrencyCode’, true);

Retrieve the Cache key

The platform cache behaves like a map get ant put. To retrieve the ‘hasCurrencyCode’ key, simple use the Cache class get method.

Boolean hasValue = (Boolean) Cache.Org.get(‘hasCurrencyCode’);

We can also get the partition first and then can retrieve the key value.

Cache.OrgPartition orgPart = Cache.Org.getPartition('local.testCache);

Boolean hasValue = (Boolean) orgPart.get(‘hasCurrencyCode’);

Similarly, for the Cache.Session class.

Cache.SessionPartition sessionPart = Cache.Session.getPartition('local.testCache);

To see platform cache action, please follow part 2 of this blog.

Leave a Reply