Mule 4 – Cache Scope

Background

When implementing services, there would be a need to use different types of data to process input. For example, there may be a need to cross-reference for a transformation, which could be primarily static data. Another example would be to re-use a token generated to invoke a service. In this second example, the data may be valid only for a certain time (temporal data), after which a new token needs to be generated. For re-use of the same data, MuleSoft provides Object Store to cache. The Object store offers a maximum of 10 TPS, and for higher loads, one may purchase a better plan that can support up to 100 TPS. But before we decide on using the object store, one may also assess if this data could be stored as part of the in-memory cache.

Cache-Scope

In Mule 4, Cache scope is a group of processors that execute and store (cache) the output in-memory. A cache-scope is configured with a key identifier that may be mapped to a value from the Mule event. For example, an attribute or a variable. The cache-scope keeps track of the results of its processing against the key identifier, as illustrated in the diagram below. When a cache-scope is invoked, it checks to see if the key was already processed, and if the result is cached. If the scope was already executed with this key, and the result was indeed cached, then the result is returned without executing it again.  On the other hand, if the cache-scope was invoked with a new key, that was not executed earlier (cache-miss), the processors within the scope are executed, the results are returned and stored in the cache for later use.

Use Case – Storing the Token

Here is a description of using cache-scope for storing a temporal token. Illustrated below is a diagram The generate-token runs every 30 minutes and generates a new token stored in the Object Store. As we do not want to access Object Store for each incoming request, we implemented a sub flow that gets the token from the object store within a Cache-scope. The key identifier is set to a variable, request_token and the value for that is set to a constant, “current_token”. Since this is a constant, the scope is executed only once, and for subsequent calls for the token, it is returned from the in-memory cache. In our scenario, every 30 mins, the token expires. So, when a new token is generated, a processor is used to invalidate cache. This ensures that the retrieval is performed from the object store from within the cache-scope, once per every 30 mins. This invalidation helps with keeping the cache updated with the current value even when the cache key is still unchanged. You could use persistent or non-persistent cache based on the need. Also, there are implications on the availability of the cached data across multiple workers within the same applications. One may decide the mode of caching depending on the context of the problem.

Summary

Cache-Scope within a MuleSoft application helps with storing the latest data in-memory so that it can be retrieved faster without any overhead costs. However, to add a word of caution, as the worker memory is primarily utilized to process incoming requests, one should be mindful of the amount of data being cached. If it is a large amount of cached data, then the architect could consider other ways of caching, may be through a separate in-memory cache implementation such as Redis. Using Mule 4 Cache scope helps with leveraging application for high throughput of requests without the need to make expensive I/O operations or requests to Object Store. One may decide the mode of caching depending on the context of the problem. You could use persistent or non-persistent cache based on the need. Also, there are implications for the availability of the cached data across multiple workers within the same applications.