Choosing a Caching Backend in Moleculer: Memory vs. Redis

The Caching Dilemma in Distributed Services

In a read-heavy microservices architecture, repeatedly executing the same action with the same parameters wastes CPU and database resources. Moleculer provides built-in caching to intercept these requests, but the choice of backend—MemoryCacher or RedisCacher—determines whether your system maintains data consistency across replicas or suffers from "cache fragmentation," where different service instances return different versions of the same data.

Comparing Caching Backends

The decision depends on whether your data is instance-specific or shared across the cluster, and whether you can tolerate temporary inconsistencies during service restarts.

Feature	MemoryCacher (Default)	RedisCacher
Latency	Near-zero (Local RAM)	Low (Network round-trip)
Scope	Process-local	Distributed (Shared)
Persistence	Cleared on restart	Persists across restarts
Consistency	Fragmented across nodes	Unified across nodes
Infrastructure	None required	Requires Redis instance

Trade-offs and Constraints

MemoryCacher is ideal for immutable data or configuration values that rarely change. However, in a clustered environment, if you update a record on Node A, Node B will continue serving the stale cached version until its local Time-To-Live (TTL) expires. This makes it unsuitable for data where consistency is critical.

RedisCacher solves the fragmentation problem by centralizing the state. All service replicas query the same Redis store. The trade-off is the introduction of a network dependency. If the Redis cluster becomes unavailable, your services may experience increased latency or errors depending on how the cacher is configured to handle failures.

Implementation: Configuring RedisCacher

To implement distributed caching, you must define the cacher at the service level. This example assumes you are using Moleculer v5.x or v6.x.

// services/user.service.js
module.exports = {
  name: "users",
  cacher: {
    // Use RedisCacher for shared state
    type: "redis",
    redis: {
      host: "127.0.0.1",
      port: 6379,
      db: 0,
    },
    // Prefix prevents key collisions in shared Redis environments
    prefix: "moleculer-users",
  },
  actions: {
    getProfile: {
      // Cache this action for 60 seconds
      // Only use 'id' from params to generate the cache key
      cache: { 
        keys: ["id"], 
        ttl: 60 
      },
      handler(ctx) {
        return this.global.db.users.findOne({ id: ctx.params.id });
      },
    },
  },
};

Operational Risks and Limitations

• Bypassing Logic: Cached actions skip the normal execution flow. This means before hooks, input validation, and authorization checks are not executed for cached hits. Ensure that security checks are performed at the API Gateway level or handled within the cache key logic.
• Manual Invalidation: Moleculer does not automatically clear related cache keys when data changes. If you update a user profile, you must manually call this.broker.cacher.clean("users.getProfile", params) to prevent serving stale data.
• Key Collision: Without a unique prefix in the RedisCacher config, multiple services or environments (staging vs. production) sharing one Redis instance may overwrite each other's cache entries.

Validating the Cache State

To verify that RedisCacher is working across multiple instances, follow these steps:

1. Start two separate instances of your service.
2. Invoke the cached action on Instance A.
3. Invoke the same action on Instance B.
4. Check the Redis store using the CLI to confirm the key exists and is shared:

# Run on the machine hosting Redis
# Replace 'moleculer-users' with your configured prefix
redis-cli --scan --pattern 'moleculer-users*'

If you are using MemoryCacher, the redis-cli command will return no results, and restarting a single service instance will immediately wipe its local cache, forcing a fresh database hit on the next request.