Solving Performance Bottlenecks with Salesforce Platform Cache Partition
At one point, the system integration team issued a directive that every client communicating with the server had to obtain a token from the API Gateway. This is generally a simple and common flow, meant to centralize token issuance and access control — Salesforce included, as one of the clients.
I initially tried the usual approach: calling the token endpoint directly via a future method every time an API call was made, the same pattern used by hundreds of other services. However, this turned out to be quite risky, since the token service had a rate limiter in place to restrict the number of token requests.
Recognizing this, I created a dedicated custom object to store the token and registered it with a Scheduler.
Once this was running, a new problem emerged. The object-based token approach turned out to be highly inefficient — querying the object before every service call meant a significant increase in response time, especially given that thousands of services needed to attach the token in their request headers as part of daily transactions.
This is where Platform Cache Partition came in as a solution: storing the token value temporarily without the need for repeated queries.
Salesforce natively provides Platform Cache, a feature used for general-purpose temporary data storage within the scope of an instance, in its programming language, Apex — similar in concept to Redis, Memcached, and other caching solutions. Developers can define keys and values, set a time-to-live, and configure visibility scope, although in terms of features and configuration flexibility, it doesn’t match the depth of other caching software like Redis.
Platform Cache for what?
- Avoid calling values from the query immediately and repeatedly
For example, if you call an authentication service to obtain a token, instead of storing it in an object and a custom field like this:
You can utilize a caching platform to store the data and retrieve it via the header in other services.
- Saving state around the request
The Cache Partition platform can also serve as a mechanism for state distribution within transactions on a single instance — whether across requests or users — provided the data to be stored is not excessively large.
This enables any request requiring state from another event to simply pull or retrieve the data from the cache to obtain the latest state.
- Avoid governor limits
Salesforce imposes limits (governor limits) on the number of SOQL queries, callouts, and similar operations within a single transaction. Relying heavily on queries or callouts across a large volume of transactions carries significant risk. While Queueable and Batchable interfaces can be used to handle this; processing times would become excessively long.
By using caching, we can reduce the number of queries, as previously retrieved data can be reused.
Difference between org and session cache
There are two approaches to Platform Cache: Org Cache and Session Cache. Org Cache can store values for a duration ranging from 5 minutes (by default) up to 48 hours; in contrast, Session Cache is limited to a maximum of 8 hours and is tied to user login and logout activity.
Get Ichwan Sholihin’s stories in your inbox
Join Medium for free to get updates from this writer.
However, Session Cache stores information on a per-user basis — meaning each user has access to their own specific cache — whereas Org Cache does not have partitions between users.
There is a configuration aspect that differs from standard Salesforce setups: Platform Cache usage can be distinguished by package — similar to a library — when you install an external package or use the package manager.
This makes it possible to avoid Partition Name collisions with other packages.
Start using the platform cache
There are two ways to define a cache partition in Apex: by declaring it directly using the format namespace.PartitionName.key:
Cache.Org.put('local.MyPartition.userStatus123', 'IN_PROGRESS');
Object value = Cache.Org.get('local.MyPartition.userStatus123');Or a more concise and readable version by declaring the namespace and partition name first:
Cache.Partition orgPart = Cache.Org.getPartition('local.Assessment');
orgPart.put('userStatus123', 'IN_PROGRESS');
Object value = orgPart.get('userStatus123');Is it limited to just declaring keys and values? Not yet. We can also add other parameters such as TTL, visibility, and isImmutable.
Here are the parameter details for the Platform Cache Partition:
- key: A key name formatted as
namespace.partitionName.key. Each defined cache must have a unique key, or use the same key with a different namespace. - value: The stored data must be serializable; it can be a primitive, sObject, collection, or even a custom class.
- TTL: Time-to-Live in seconds, determining how long the data persists before automatically expiring.
- visibility: An optional parameter with two settings:
Cache.Visibility.ALL(accessible by other namespaces) orCache.Visibility.NAMESPACE(accessible only within the same namespace); this is typically relevant when using managed packages. - isImmutable: Also an optional parameter; if set to
true, the stored value cannot be overwritten by code from another namespace (e.g., from a different managed package installed in the same org).
Is Platform Cache same as Platform Event?
They are clearly different. Simply put, Platform Cache is limited to shared state or a pull-based model; components requiring a value must pull it from the cache using a registered key, and there is no history or event-based messaging within Platform Cache. This contrasts with Platform Events, which employs an event-driven architecture where specific events are published and subscribed to using Apex Triggers, Flows, or CometD.
Platform Cache is effectively used for data that is frequently accessed, rarely changes over a specific period, and is costly or risky to retrieve — such as authentication tokens, external API callout results, or reference data that is resource-intensive to query. By temporarily storing these values in memory (rather than in a database or via repeated callouts), the system becomes faster, more resource-efficient, and less susceptible to rate limiting.
Before you go
- Please take a moment to like the post and follow the writer!
- Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here.
