Crate distributed_cache 

The distributed cache — Rust port of the Java engine’s extensions/distributed-cache (org.platformlambda.cache, v4.12.9; design spec draft-design-specs/distributed-cache.md in the Java repo, Q1–Q8; this port’s spec draft-design-specs/distributed-cache-port.md).

A generic Redis-backed L2 key-value cache exposed as one composable action function, route CACHE_ROUTE (v1.cache.redis), over opaque byte values — the caller owns serialisation, which is what lets any layer and any language share the cache. An action header selects the operation; key(s) and TTL ride in headers, value(s) in the body.

Type	Java class	Role
CacheAction	CacheAction	the bounded, cache-shaped operation set
CacheConfig	CacheConfig	redis.cache.* tunables over the plain redis.* connection namespace
RedisCacheStore	RedisCacheStore	the operations over the shared RedisBackend — cluster-safe, every key TTL’d from birth
runtime	CacheRuntime	the process-wide, lazily built store over ONE multiplexed connection
RedisCache	RedisCache	the #[preload] function v1.cache.redis, gated by redis.cache.enabled
CacheRedisHealthCheck	CacheRedisHealthCheck	the redis.health binding of the foundation’s probe

Two composable functions self-register when this crate is linked into an application AND redis.cache.enabled=true (reference the crate from main.rs so the linker keeps its registration inventory — the Java “include the jar” deployment story):

• v1.cache.redis — the cache; redis.cache.instances (default 20) is worker concurrency, NOT a connection count: every worker shares the one multiplexed connection the runtime holds.
• redis.health — the /health probe of the cache’s Redis; add it to mandatory.health.dependencies or optional.health.dependencies.

This crate is imported by the APPLICATION, never by the engine — a cache is a deployment choice. It does not depend on sync-over-async; both depend on the redis-connection foundation, in the Java dependency direction.

Cross-engine contract. Cache keys are plain Redis keys ({redis.cache.key.prefix}{key}), values are the caller’s bytes, the action names and the configuration keys are the Java engine’s — so a Java pod and a Rust pod configured alike read and write one cache.

Modules

runtime

Process-wide holder of the cache’s single shared, multiplexed backend and the RedisCacheStore over it — Rust port of the Java CacheRuntime. Every v1.cache.redis worker instance calls store and shares this one connection: redis.cache.instances is worker concurrency, not a connection count (design spec §4.4: no pool; the client pipelines over one in-order connection).

Structs

CacheConfig

The resolved cache configuration (Java CacheConfig record).

CacheRedisHealthCheck

redis.health — registered by the preload inventory alongside the cache function when redis.cache.enabled=true.

RedisCache

v1.cache.redis — the cache as one action function. Registered by the preload inventory when the application links this crate and redis.cache.enabled=true; every call resolves the shared store lazily.

RedisCacheStore

The cache operations (Java RedisCacheStore). Commands that are safe to run twice (SETEX, GET, MGET, MPUT, DEL, LLEN) go through the backend’s idempotent path and are retried once when the connection was lost to a restart; SET NX, RPUSH and LPOP are never replayed (redis_connection::backend, Lifecycle).

Enums

CacheAction

One cache operation, selected by the action header (case-insensitive).

Constants

CACHE_ENABLED_KEY

redis.cache.enabled — the opt-in master switch.

CACHE_INSTANCES_KEY

redis.cache.instances — worker instances of v1.cache.redis.

CACHE_ROUTE

The cache function’s route.

DEFAULT_TTL_KEY

redis.cache.default.ttl — the TTL a write uses when it omits ttl.

HEALTH_ROUTE

The cache’s health-check route — the plain-named counterpart of sync-over-async’s soa.redis.health.

KEY_PREFIX_KEY

redis.cache.key.prefix — the application namespace prepended to every key.

Functions

handle

The action dispatch over a given store (Java RedisCache.handleEvent) — public as the reuse/test seam the Java constructor-injected Supplier provides: drive the contract against any store, e.g. one built against an in-process server.