Module cache 

Cache store extension point.

Contract: CacheStore

Purpose: opaque byte-level get/set/delete storage for response caching and any hot-path shared state. Keys are strings; values are owned byte vectors so backends can move them without copying.

Semantics: a best-effort store, not a durable database. set overwrites any existing value; delete of a missing key is a no-op reporting false. DW-037 added the optional TTL seam the M1 doc anticipated: CacheStore::set_with_ttl carries a per-entry lifetime hint, DEFAULTED to plain set so every existing implementation keeps compiling and remains a valid backend — the response cache layer stamps expiry into the value envelope and enforces it at READ, so backend TTL is a memory-reclamation optimization, never a correctness dependency.

Failure model: backend failures map to ExtensionsError::Backend; call sites should treat cache errors as a miss (degrade, do not fail the request). No retries.

Editions: OSS ships InMemoryCache (process-local LRU-bounded map) and MokaCache (the DW-037 response-cache backend: concurrent, byte-weighed, per-entry TTL). Additional distributed backends (DW-068 Redis) may be provided separately in future editions.

Structs

InMemoryCache

In-memory LRU cache (OSS local impl, #128).

MokaCache

Byte-weighed TTL cache over moka (DW-037 response-cache backend).

Constants

DEFAULT_CACHE_CAPACITY

Default InMemoryCache capacity (entries, not bytes): enough for a small deployment’s hot response set while keeping the store bounded against key-flooding (#128, DW-004 review).

DEFAULT_CACHE_STORE_BYTES

Default MokaCache capacity (bytes, DW-037): the weigher counts key + value bytes plus a fixed per-entry overhead, so the bound is a real memory ceiling for the response cache (entries at or under the per-route max_body_bytes cap, of which 64 MiB holds hundreds).

Traits

CacheStore

Swappable key/value cache backend.