Setting Up Redis External Caching

Overview

A Redis server must be deployed for external caching to expand operations across multiple servers. The Decisions servers and the Redis server communicate through API calls to store and retrieve objects, helping support clustering across multiple instances. While internal caching acts as a local dictionary that clears old items when accessed, external caching supports communication between instances and the database.

Decisions also supports configuring a Channel Name in Clustering Settings. The Channel Name is used as a Redis key/channel prefix, allowing multiple environments, such as Production, Performance, and Test, to share the same Redis cluster while maintaining logical isolation and preventing key or channel collisions.

Decisions Uses Redis in Two Ways

Redis as Pub-Sub Model

When an entity is modified on Server 1, the updated information is stored in the database and sent to Redis for caching. Redis then broadcasts this cached data to all other servers in real-time, ensuring that if a user accesses a different server, they will see the exact, updated details from the database.

Redis as Cache

Redis stores information about which server owns the cache for the Flow engine data, but does not directly store the cached data itself. Each server manages its own cache independently, and Redis serves as a lookup mechanism for determining the cache owner.

For example:

When a user on Server 1 initiates a Flow, completes the process from their end, and assigns a Form to a second user, the information about the Flow is stored locally on Server 1. In addition to this, the information, including the Flow ID and server details, is sent to Redis, indicating that Server 1 is responsible for the cached data associated with that particular Flow.

When the second user from Server 2 tries to access the same Flow to complete the assignment, Server 2 checks Redis for the stored information instead of searching all servers or the database. If the Flow ID information is found in Redis, Server 2 learns that Server 1 owns the cache for that Flow. Consequently, Server 2 contacts Server 1 directly to retrieve the cached data for the Flow. Once the second server maintains the cache, the information is sent back to Redis, designating Server 2 as the owner of the cached data for Flow.

Note:

Decisions does not store any user data or session-related data in Redis.

Redis System Recommendations

Connecting to the Redis server

After meeting all the prerequisites listed under the overview section, the following subsection explains how to connect Decisions with the Redis server.

1. Log in to Decisions. Select the gear icon on the left taskbar, then navigate to System > Settings > Clustering Settings.

2. Enable Turn On Clustering and then enter the Redis URL.

3. Optionally, configure the Channel Name in Clustering Settings. This value is used as a prefix for Redis keys and channels, enabling multiple environments (such as Prod, Perf, and Test) to share the same Redis cluster without key or channel collisions.

   • The default value is Decisions.
   • If changed, a server restart is required for the update to take effect.
     Channel Name Configuration via Environment Variable:

     The Channel Name can also be configured using an environment variable: DECISIONS_CLUSTERING_CHANNELNAME={name}

4. This example utilizes the default localhost Redis URL localhost:6379. If a wrong connection string is entered, a validation stating, "Failed to validate Redis connection string," will be thrown.

   URL Configuration Options

   • Users can configure the Redis configuration options in the connection string field by adding a comma. E.g., localhost:6379, Password=null, allowAdmin=true etc.

   • Refer to Configurations from StackExchange.Redis for a complete guide on all the parameters.

5. Restart the Decisions server.

FAQs on Redis

• Does Decisions Support Redis Clusters?

  • Yes, from the automation platform perspective, as long as the connection to Redis is set up correctly.

• Can the same Redis Cluster be used for Multiple Tenants?

  • Yes. Since Decisions uses Redis as Pub-Sub, using the same Redis instance for multiple tenants is supported as long as it is specified appropriately.

• What would be the memory footprint of each Decisions Cluster on the Redis Cluster?

  • The memory footprint depends on the number of active flows a customer has. However, the footprint is relatively small since Redis is used solely for communicating object IDs between clusters.