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).

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.