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

The short answer

If your data must survive restarts and stay consistent across multiple service instances, use the Redis-backed cacher — but only after measuring whether the added round-trip fits your latency budget. For single-instance services or data that can be safely recomputed, the built-in memory cacher is the right default. The two are not interchangeable: they answer different consistency requirements, so the decision should be driven by your staleness tolerance, not by latency alone.

Acceptable latency increase from Redis

There is no universal number — the acceptable increase is whatever remains in your per-request latency budget after the downstream work. The overhead comes from three places: network round-trip time to Redis, serialization/deserialization of cached values, and connection handling. On a same-host or same-AZ Redis with small payloads, a cache read commonly lands in the low single-digit millisecond range, versus effectively sub-millisecond for in-memory. Whether that is acceptable depends entirely on your p99 target.

The only reliable way to decide is to measure in staging:

• Run the same request path against the memory cacher and the Redis cacher under representative peak load, and compare p50/p95/p99.
• Keep cached payloads small; large serialized objects dominate the Redis cost more than the RTT does.
• Co-locate Redis with your brokers/nodes to keep RTT minimal, and use connection pooling rather than opening connections per request.

If the Redis read pushes you over budget, a two-tier pattern is worth considering: a short-TTL in-memory layer in front of Redis, which absorbs hot reads while Redis remains the shared source of truth. This adds invalidation complexity, so adopt it only when measurements justify it.

Aligning TTL and invalidation across the two stores

The stale-data risk after a restart comes from asymmetry: memory cache dies with the process, Redis does not. To keep behavior predictable:

• Single source of TTL truth. Set TTLs in the cacher configuration and let Redis enforce expiration natively, rather than managing expiry in application code. Verify actual behavior with redis-cli monitor or TTL <key> in staging, because expiration semantics can differ between cacher versions and Redis configurations — treat this as a verify-before-deploy item.
• Prefer event-based invalidation over long TTLs. Moleculer lets you clean cache keys when entities change (e.g., via the cacher's clean on specific keys or patterns triggered by domain events). This is what makes cross-instance consistency work: an update on node A invalidates the shared Redis entry, so node B never serves the old value. With pure in-memory caching, node B has no way to know.
• Size TTLs to your staleness tolerance. If consumers tolerate 30 seconds of staleness, a 30-second TTL plus event-based invalidation on writes is simpler and safer than a long TTL with manual purges.

Fallback behavior when Redis is unreachable

A Redis outage must degrade to a cache miss, not a request failure. Concretely:

• Configure the Redis client with bounded reconnect attempts and a command timeout, so a hung connection fails fast instead of blocking requests until your upstream gateway times out.
• Wrap cache reads so that a Redis error is logged and treated as a miss, falling through to the underlying action/data source. Confirm your plugin version's error behavior in staging — do not assume misses are silent.
• Protect the fallback path: when Redis is down, every request hits the real data source. If that source cannot absorb full traffic, add a circuit breaker or a short-TTL local memory fallback so a Redis blip does not become a database outage.
• For production, run Redis with Sentinel or Cluster so a single node failure does not trigger this path at all — a lone Redis instance is a single point of failure.

Simulate the failure before you ship: stop Redis in staging under load and confirm requests degrade to slower-but-successful responses within SLA, then recover cleanly when Redis returns.

Decision rule

Multi-instance deployment or restart-survival requirement → Redis cacher with event-based invalidation, fail-fast client settings, and miss-on-error fallback. Single instance, recomputable data, tightest possible latency → memory cacher. If latency measurements rule out Redis for the hottest path, layer a short-TTL memory cache in front of Redis rather than abandoning shared state entirely. The one detail that could change this recommendation is your measured p99 budget per request — if it is under ~5 ms end-to-end, the two-tier design stops being optional.