Platform Cache in Salesforce

In this session, we will talk about Platform Cache in Salesforce. We will talk about how to Boost your app‘s performance significantly and Understand which kind of data to put in the cache. Know the obstacles when you use the platform cache and prepare for cache misses and unexpected results. In post/session we will learn about

  1. Learn using the platform cache can boost your app‘s performance significantly
  2. Understand which kind of data to put in the cache
  3. Know the obstacles when you use to the platform cache and prepare for cache misses and unexpected results

What is Platform Cache in Salesforce?

Platform Cache is a memory layer that store’s Salesforce session and org data for later access. “Platform Cache” is just like a RAM for your app. With Platform Cache, your applications can run faster because they store reusable data in memory. “Platform Cache” is used to to store Static Data, complex computations  and Frequently used data

Type of Platform Cache

1) Org Cache :- Org wide data for anyone in the org
2) Session Cache :- Data for a specific user stored up to 8 hours

How to Setup Platform Cache

1) Click on Setup then Type “Platform Cache” in Quick Find. Then click on “Platform Cache”
2) Request for Free Trial if “Platform Cache” is not available for your org (Optional Step)

Platform Cache in Salesforce

3) Then click on “New Platform Cache Partition” and the provide the “Name” all required detail
4) Make the first Partition as Default Partition.

Store and Retrieve Data in Org Cache

After partitions setup, we can use the Cache.SessionPartition and Cache.OrgPartition class’s to add, retrieve, or remove values from a partition’s cache. Use Cache.Session and Cache.Org classesto get a partition or perform cache operations by using a fully qualified key.

Handling Session cache:-

// Add a value to the cache . local is the default name space cache
Cache.Session.put('local.MyFirstPartition.key', '1234567');

// Check value is there in Cache
if (Cache.Session.contains('local.MyFirstPartition.key')) {
    // get Cache value
    String key = (String)Cache.Session.get('local.MyFirstPartition.key');
}

Handling Org Cache:-

// Get partition
Cache.OrgPartition orgPart = Cache.Org.getPartition('local.MyFirstPartition');

// Add cache value to the partition
orgPart.put('key','welcome');

// Retrieve cache value from the partition
if (orgPart.contains('key')) {
    String key = (String)orgPart.get('key');
}

Key Concepts

Let see the key concept of Platform Cache in Salesforce.

  • Simple & temporary Key-Value-Storage (Map)
  • Quite Easy to implement ANY cache strategy
    • => but Fairly Easy to design a GOOD, sustainable strategy
  • By default VISIBLE and MUTABLE
    • => but can be RESTRICTED and set to IMMUTABLE

Which kind of data to put in the cache

  • PREPARABLE – REUSABLE
  • Static: Not changing frequently
  • Frequently needed in operations
  • Expensive to get (or keep) (in terms of system limits)
  • e.g. Taxonomies, Schedules, Mappings, Conversion Rates, etc.

Considerations.

Where‘s the catch?

  1. It‘s still a cache, not a database.
  2. It is short lived and per default visible and mutable
  3. Understand the key concepts of the platform cache (in particular TTL, LRU)
  4. Expect the cache to fail you.
  5. What’s your strategy to invalidate cache?
  6. The Cache will go away… Schedule a Cache Rebuild < TTL
  7. Cached items will be pushed out… Use the CacheBuilder interface
  8. Cached data goes stale… Rebuild From Triggers
  9. Cached items must adhere to the 100kB size limits Reduce memory footprint by using Apex Classes instead of sObject or reduce the number of queried fields
  10. Don‘t use the cache as a fast, limit-free database.
  11. Don‘t use it as temporary storage for transactional data
  12. No items larger than 100kB
  13. Cached Items are not persisted – don‘t rely on them being there.
  14. Unless flagged as immutable, don’t rely on the integrity of cached items

Best Practices of platform Cache in Salesforce

  1. Cache lists or maps of objects rather than single objects.Tradeoff: Better performance of fewer, larger operations vs. 100kB item size limit
  2. Use a wrapper class to reduce sObject overhead
  3. Use the fully qualified name of your cache partition
  4. Consider using the ‘immutable‘ flag and the visibility enum

Platform Cache in Salesforce Video

YouTube video

Here is PPT of session.

Further Reading

  1. Developer Documentation: bit.ly/cachedoc
  2. Trailhead: bit.ly/cachetrail
  3. Session Code: github.com/dstdia/PlatformCache/
  4. Keir Bowden’s blog post: bit.ly/cache-buzzard
  5. Josh Kaplan‘s blog post: bit.ly/cache-sfblog
  6. Amit Chaudhary: http://bit.ly/cache-amit

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates.

He is a active blogger and founder of Apex Hours.

Articles: 459

Leave a Reply

Your email address will not be published. Required fields are marked *