Choosing between in‑memory and Redis‑backed caching in Moleculer for latency‑critical services

Cache strategy decision for Moleculer services

Goal: select a caching mechanism that meets the latency budget of a production API while ensuring cached data survives process restarts and is consistent across multiple instances.

Constraints: the native in‑memory cache delivers sub‑millisecond read times but is lost on restart and does not share state between nodes; the moleculer‑cache plugin with Redis adds network round‑trip latency, introduces dependency on Redis availability, and may exhibit different TTL expiration semantics depending on the plugin version and Redis configuration.

Uncertainty: how the combined latency of a Redis round‑trip compares to the latency budget under peak load, and whether occasional Redis connectivity glitches will cause cache misses or errors that affect SLA.

What is the acceptable latency increase when using Redis‑backed caching for a typical request path?
How should TTL and invalidation policies be aligned between the two stores to avoid stale data after a restart?
What fallback behavior should be configured for the moleculer‑cache plugin when Redis is temporarily unreachable?