Thanks — I’m responding to your question about the best way to share/cache data on agent servers between workers. Short answer • Do not rely on in-process memory to share cache between workers. Agent sessions run in isolated processes, so

userdata

or in-memory dictionaries are only visible to that single process. • Use an external/shared cache (Redis, Memcached, or a shared DB/volume) so all workers can read/write the same cached data. Redis is the recommended pattern for low-latency, cross-worker caching, persistence across restarts, and coordination. Why this approach • Each agent job runs in its own process, so process-level caches (e.g.,

JobProcess.userdata

) work only for reuse inside that process — they are not synchronized across other worker processes. • For HA and load-balanced deployments you’ll have multiple workers; only an external store provides a single source of truth all workers can access. • Using a distributed cache also lets you handle expiration, eviction, replication, and persistence policies centrally. Practical options and trade-offs • Redis (recommended) ◦ Pros: fast reads/writes, pub/sub for invalidation, TTLs, widely supported clients. ◦ Use-case: small to medium-sized objects (tokens, metadata, precomputed results), coordination (locks), cache invalidation via pub/sub. • Memcached ◦ Pros: very fast for simple ephemeral caches. ◦ Use-case: pure ephemeral caches where persistence or pub/sub isn’t needed. • Database (Postgres, etc.) ◦ Pros: persistence and complex queries. ◦ Cons: higher latency than in-memory caches → use for larger or critical state rather than hot caches. • Shared disk/volume (NFS, S3-backed file store) ◦ Use-case: large static artifacts (pre-synthesized audio files, model binaries) that workers can read from disk. Good for media assets but higher I/O latency for many small reads. • Hybrid approach ◦ Keep hot items in Redis and larger or static assets on shared disk. Pre-warm worker-local process caches from Redis or disk at startup to reduce runtime latency. Implementation tips 1. Store small serializable values (JSON, binary blobs) in Redis with sensible TTLs. 2. Use Redis pub/sub or a key-version pattern to invalidate local process caches when data changes. 3. If you keep per-process caches (for performance), always treat them as a read-through cache backed by Redis so misses and invalidation are consistent. 4. For media (TTS/audio), pre-generate and store files on shared storage and optionally cache recent items in Redis or the worker process. 5. Use locks (Redis SETNX or Redlock) for race-sensitive operations (e.g., one worker generating a heavy artifact). If you want, I can: • Suggest a sample Redis key design for the kinds of items you plan to cache (tokens, precomputed responses, audio files). • Show a short code example (Python/Node) for read-through caching with local process userdata + Redis backing. • Help pick TTL/eviction strategies based on the size and volatility of your cache items. Which of the above fits your use case best — small metadata, pre-synthesized audio, model artifacts, or something else? That will help me tailor the key design and example code. Sources: Examples | livekit/livekit_composite | DeepWiki | MCP Agent | LiveKit Documentation | Simple Content Filter | LiveKit Documentation | examples/dtmf | livekit/livekit_composite | DeepWiki | Server options | LiveKit Documentation