Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Boost your App with Platform Cache Learn how to leverage the platform cache to improve your app's performance, Daniel Stange


Published on

For Web Applications, caching is a common strategy to improve performance and reliability. Yet, it’s a lesser known feature that there is “Platform Cache” as a built-in mechanism for Salesforce developers to add to their app design. Leveraging the Platform Cache can reduce your SOQL queries for certain types of data and can cut the retrieval time for data to just a few Milliseconds. 10 MB of Platform Cache are free for all orgs starting from Enterprise Edition, so you can start right now in your sandbox without the need for extra licenses.
Use cases for the Platform cache is everything that's either expensive to retrieve from the database or expensive to hold in the memory. This could be all kind of data that isn't changing too often, but crucial for Apex code (and especially code run from the frontend or in Triggers, while users are waiting and seeing a spinner): Schedules, mapping tables, taxonomies, pricing logic - at this point, you will have read at least one keyword for some Apex heavy lifting that is implemented in your org as well.
The starting point are just a few lines of Apex: The Cache.CacheBuilder interface is easy to implement and wraps just a SOQL query to execute to handle cache misses. So within minutes, your implementation can be up and running and handle one of the biggest risks for caches, which is a ""miss"" - data, that should be there but is not. Platform Cache has a strict policy for Time to Live (TTL) and eviction strategies if you run out of memory (LRU), so it's very likely that one particular value is just not there when you need it. Another threat is stale data in your cache, and some basic invalidation is also already implemented by the platform.
In the github repo for the session (, you can find a sample implementation for Platform Cache, including an example for the CacheBuilder interface, an example for a custom Cache Manager class, and some benchmarking scripts, as well as the presentation and the essential reads for this topic. If you want to connect with Daniel, reach out via Twitter (@stangomat), LinkedIn ( or Email (

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Boost your App with Platform Cache Learn how to leverage the platform cache to improve your app's performance, Daniel Stange

  1. 1. Boost your App with Platform Cache Learn How Caching Can Improve Your App’s Performance by Daniel Stange * DIA die.interaktiven
  2. 2. #CD19 20x certified System & Application Architect Frankfurt User Group Leader @stangomat Daniel Stange Technical Architect DIA die.interaktiven
  3. 3. #CD19 ● Platform Cache? But why? ● Key Concepts ● Getting Started with Platform Cache (Demo / Code!) ● When to Use (and when not to use) Platform Cache Agenda
  4. 4. #CD19 ● Learn using the platform cache can boost your app‘s performance significantly ● Understand which kind of data to put in the cache ● Know the obstacles when you use to the platform cache and prepare for cache misses and unexpected results Key Takeaways
  5. 5. #CD19 Platform Cache? But why?
  6. 6. #CD19 Avg. to fetch 10000 records as a Map through SOQL 182-370ms 1.8 to 5.7x Faster Access 65-97ms Avg. to fetch the same map from the Org cache Impact for read access to data (EE Scratch Org on CS83 / EE Dev Sandbox on CS86)
  7. 7. #CD19 DB vs. Cache Retrieve / per Item Impact of bulkification (100 retrieved values) DB: Initial 367ms => 3,67ms per item access Cache: Initial 117ms => 1,17ms per item access DB: avg. 11,52ms Cache: avg. 3.67ms
  8. 8. #CD19 Key Concepts
  9. 9. #CD19 ● Simple & temporary Key-Value-Storage (Map<String, Object>) ● 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 Platform Cache
  10. 10. #CD19 ● PREPARABLE - REUSABLE ● Static: Not changing frequently ● Frequently needed in operations ● Expensive to get (in terms of system limits) ● e,g, Taxonomies, Schedules, Mappings, Conversion Rates, etc. Data to Cache
  11. 11. #CD19 Cache Types ORG one cache for all users and contexts longer TTL SESSION scoped per user Session TTL = Session length
  12. 12. #CD19 ORG: 24 hrs DEFAULT TTL Time-to-Live (TTL) ORG: 5 min MINIMUM TTL SESSION: 5 min ORG: 48 hrs MAXIMUM TTL SESSION: 8 hrs
  13. 13. #CD19 LRU: Least Recently Used Eviction Strategy 1 4 3 7 5 6 ORDER OF LAST ACCESS 2 CACHE CAPACITY
  14. 14. #CD19 How to get started
  15. 15. #CD19 ● Enterprise Editions Sandboxs come with a 10 MB capacity ● Request a trial capacity if you are using a Developer Org or Scratch Org ● Trailhead: “Platform Cache Basics” Preparation Work
  16. 16. #CD19 Place your screenshot here Cache .[Org/Session] .put( Namespace .PartitionName .Key, Object ); Store
  17. 17. #CD19 Place your screenshot here Retrieve Cache .[Org/Session] .get( Namespace .PartitionName .Key );
  18. 18. #CD19 Sample Implementation and Benchmark Scripts at Demo
  19. 19. #CD19 Place your screenshot here Sample Sales District ◇Everything with Country = DE and PostalCode LIKE ‘35%’ should be assigned and have Nils as an Owner. dstdia/PlatformCache
  20. 20. #CD19 Place your screenshot here Creating an Account ◇Postal Code starts with 35 and Country = DE ◇Should end up in Central Sample District being assigned dstdia/PlatformCache
  21. 21. #CD19 Place your screenshot here And there it is! dstdia/PlatformCache
  22. 22. #CD19 dstdia/PlatformCache
  23. 23. #CD19 dstdia/PlatformCache
  24. 24. #CD19 dstdia/PlatformCache
  25. 25. #CD19 Considerations
  26. 26. #CD19 ● It‘s still a cache, not a database. ● It is short lived and per default visible and mutable ● Understand the key concepts of the platform cache (in particular TTL, LRU) ● Expect the cache to fail you. ● What’s your strategy to invalidate cache? Nice! Easy! Fast! Where‘s the catch?
  27. 27. #CD19 ● The Cache will go away... Schedule a Cache Rebuild < TTL ● Cached items will be pushed out… Use the CacheBuilder interface ● Cached data goes stale… Rebuild From Triggers ● 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 Build your Strategies
  28. 28. #CD19 List<CachedProduct> cachedProducts; public class CachedProduct { String name; String productCode; Decimal leadTime; } Apex Classes vs. sObjects List<Product2> products = [SELECT Name, ProductCode, LeadTime FROM Product2];
  29. 29. #CD19 (Same query, using an Apex defined type) Size matters – 100kb equals 12.5k wrapped items 9k sObjectsProduct2 records with ID, Name, ProductCode queried
  30. 30. #CD19 ● Don‘t use the cache as a fast, limit-free database. ● Don‘t use it as temporary storage for transactional data ● No items larger than 100kB ● Cached Items are not persisted – don‘t rely on them being there. ● Unless flagged as immutable, don’t rely on the integrity of cached items Repeat after me… :-)
  31. 31. #CD19 ● Cache lists or maps of objects rather than single objects. Tradeoff: Better performance of fewer, larger operations vs. 100kB item size limit ● Use a wrapper class to reduce sObject overhead ● Use the fully qualified name of your cache partition ● Consider using the ‘immutable‘ flag and the visibility enum Best Practices
  32. 32. #CD19 ● Developer Documentation: ● Trailhead: ● Session Code: ● Keir Bowden’s blog post: ● Josh Kaplan‘s blog post: ● Amit Chaudhary: Further Reading
  33. 33. #CD19 Connect with me ● @stangomat ● ● Sample Code from the session: Q&A
  34. 34. Thank you!