Skip to main content
Use this design to prepare a small cache of application context, such as a verified user’s preferred language and the timestamp of a recent lookup. Keep the authoritative record in the service that owns that data.
Threetone does not expose a user-configurable Redis context connector or a released session path that consumes this cache. Existing dynamic variables are saved authoring values. This cookbook describes a cache your application would own.

​
Before you begin

Have an authenticated application backend, a managed Redis owner, and an approved list of cacheable fields. Decide the maximum age of each field and what happens when it is missing.
1

Scope keys on the server

Derive the workspace and user identifiers from authenticated server context. Include them in the cache namespace and never accept an unrestricted Redis key from a client. Store a source version and fetch timestamp with values that can become stale. A cache hit does not grant access to the source record.
2

Restrict the Redis connection

Follow Redis security guidance for network isolation, ACLs, and TLS. Permit only the required commands and key patterns. Keep Redis credentials on the backend, outside prompts, browser bundles, mobile apps, and ordinary agent variables.
3

Set expiration with each write

Redis SET supports an expiration on the same write, such as EX in seconds. Choose the duration from the data’s freshness requirement. Review overwrite behavior so a refresh does not accidentally leave a key without expiry. Handle a cache miss by rechecking authorized source data or returning an explicit unavailable result.
4

Test stale and repeated work

Plan for Redis outage, revoked source access, concurrent refreshes, and delayed results. Never reuse one user’s context for another as a fallback. A temporary SET NX marker can coordinate work, but expiration or eviction means it cannot prove an external action executed exactly once.
Use synthetic dynamic-variable placeholders to review the expected values today. A future runtime integration must authenticate and validate context before substitution. Redis expiry does not establish deletion of logs, backups, transcripts, or provider copies; review retention limits separately.

​
Frequently asked questions

No. It controls that Redis key’s expiry. Other copies and Threetone retention enforcement have separate lifecycles and limitations.
No. Keep identity boundaries intact. Fetch authorized data for the current user or report that context is unavailable.