Configuring Caching

Caching is an optional feature available in all Neo blocks (except OrgContextSwitch and Redis Evict) that stores frequently accessed data in a temporary cache to improve performance. It helps store frequently accessed data in a temporary storage called a cache, improving performance. Additionally, the connection pool, a managed collection of reusable database connections, operates in the background as a shared resource. This means you don’t need to manually select or configure a database, as multiple blocks share the same pool instead of opening separate connections.

How does caching work
When caching is enabled in a block, Neo stores the block’s execution results. This means that when a cachable block is executed, its output is stored. If the same block is triggered again with the same identifying criteria, the stored output is retrieved from the cache instead of re-executing the block.

The caching mechanism relies on a Cache key. When a block is marked as cachable, a key is associated with its execution and resulting output. Subsequent executions of the same block will check the cache for an entry with a matching key

Types of Cache Key

Caching keys can be either static or dynamic:

Static Keys: These are fixed values that do not change based on the incoming request or context. They are suitable for caching data that remains constant, such as language-specific text or unchanging configurations. For example, a block retrieving a store's default settings could use a static key based on the store ID.

Dynamic Keys: These keys are generated based on parameters of the incoming request or from the Configuration Manager or Secret Manager using DAO functions. This allows for caching responses that are specific to certain inputs. For instance, a block fetching customer details could use the customer ID as part of the dynamic cache key. Therefore, requests for different customers would result in different cache entries.

The decision to use a static or dynamic key depends on the specific business use case and the data flow requirements.

Examples for Caching

Dynamic Key Example

Use a dynamic cache key when data retrieval depends on unique identifiers like CustomerID.

Scenario 1: First Execution

1. A request arrives with CustomerID = 456.
2. Neo checks for the cache key customer_details_456.
   • No cache data exists.
3. The API Request block fetches customer details for CustomerID = 456.
4. Neo caches the response under customer_details_456.
5. The dataflow continues.

Scenario 2: Cached Data Retrieval

1. Another request arrives with CustomerID = 456.
2. Neo checks for the cache key customer_details_456.
   • Cache data exists.
3. Neo retrieves the cached response, bypassing the API call.
4. The dataflow continues.

Scenario 3: Different Customer

1. A request arrives with CustomerID = 789.
2. Neo checks for the cache key customer_details_789.
   • No cache data exists.
3. The API Request block fetches customer details for CustomerID = 789.
4. Neo caches the response under customer_details_789.
5. The dataflow continues.

Static Key Example

Use a static cache key when accessing frequently used data that changes infrequently, such as active store codes.

Cache Behaviour:

1. On the first execution:
   • The API Request block fetches active store codes (e.g., ["STORE001", "STORE002", "STORE003"]).
   • Neo caches the response under the static key active_store_codes.
2. On subsequent executions:
   • Neo checks for the key active_store_codes.
     • If the key exists and the cached data is valid, Neo retrieves the cached list directly.
     • No additional API call is made, reducing backend load and improving performance.

Enabling Caching

To enable caching,

1. Check the Is Cachable checkbox.
2. In the Key field, define a unique identifier to store data in the cache.
3. In the TTL field, set a Time-To-Live (TTL) value for keys to determine how long a key will be stored in the cache before it expires and is automatically removed.