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 (github.com/dstdia/PlatformCache), 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 (https://www.linkedin.com/in/danielstange/) or Email (daniel.stange@die-interaktiven.de)

1. Boost your App with Platform Cache
Learn How Caching Can Improve Your App’s Performance
by Daniel Stange * DIA die.interaktiven

2. #CD19
20x certified
System & Application Architect
Frankfurt User Group Leader
@stangomat
linked.in/daniel-stange
github.com/dstdia
Daniel Stange
Technical Architect
DIA die.interaktiven

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. #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. #CD19
Platform Cache?
But why?

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. #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. #CD19
Key Concepts

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. #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. #CD19
Cache Types
ORG
one cache for all
users and contexts
longer TTL
SESSION
scoped per user
Session
TTL = Session
length

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. #CD19
LRU: Least Recently Used Eviction Strategy
1
4
3
7
5
6
ORDER OF LAST ACCESS
2
CACHE CAPACITY

14. #CD19
How to get started

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”
bit.ly/cachetrail
Preparation Work

16. #CD19
Place your screenshot here
Cache
.[Org/Session]
.put(
Namespace
.PartitionName
.Key,
Object
);
Store

17. #CD19
Place your screenshot here
Retrieve
Cache
.[Org/Session]
.get(
Namespace
.PartitionName
.Key
);

18. #CD19
Sample Implementation and Benchmark Scripts at
https://github.com/dstdia/PlatformCache
Demo

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.
https://github.com/
dstdia/PlatformCache

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
https://github.com/
dstdia/PlatformCache

21. #CD19
Place your screenshot here
And there it is!
https://github.com/
dstdia/PlatformCache

22. #CD19
https://github.com/
dstdia/PlatformCache

23. #CD19
https://github.com/
dstdia/PlatformCache

24. #CD19
https://github.com/
dstdia/PlatformCache

25. #CD19
Considerations

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. #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. #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. #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. #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. #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. #CD19
● Developer Documentation: bit.ly/cachedoc
● Trailhead: bit.ly/cachetrail
● Session Code: github.com/dstdia/PlatformCache/
● Keir Bowden’s blog post: bit.ly/cache-buzzard
● Josh Kaplan‘s blog post: bit.ly/cache-sfblog
● Amit Chaudhary: http://bit.ly/cache-amit
Further Reading

33. #CD19
Connect with me
● @stangomat
● Daniel.stange@die.interaktiven.de
● github.com/dstdia
Sample Code from the session:
https://github.com/dstdia/PlatformCache
Q&A

34. Thank you!