Enable Action Caching in Moleculer Services to Reduce Response Time

Desired outcome

After completing this guide, your Moleculer service will return cached results for repeated identical action calls, reducing response time and CPU load while preserving the ability to invalidate or disable the cache when data changes.

Prerequisites

• A Node.js project that uses Moleculer (v0.14 or later).
• Access to the broker configuration file (usually moleculer.config.js or similar).
• If you plan to use Redis as the cache backend, a running Redis instance reachable from the service.
• Basic familiarity with editing JavaScript/TypeScript files and restarting the Node process.

Procedure

1. Choose a cache storage backend

   Moleculer supports in‑memory (default), Redis, or MongoDB. For a single‑node dev setup, in‑memory is sufficient. For production or clustered deployments, Redis is commonly used because it shares cache across nodes.

2. Enable caching in the broker options

   Open your broker configuration file and add a cache section. Below are two examples; replace placeholders with your actual values.

   // moleculer.config.js
   module.exports = {
     cache: {
       enabled: true,          // master switch
       // In‑memory backend (default)
       // redis: { host: 'localhost', port: 6379 }   // uncomment for Redis
     },
     // other broker options …
   };
   

   If you use Redis, ensure the service can reach the host and port; otherwise the broker will throw an error when a cached action is invoked.

3. Configure caching for a specific action

   You can enable caching globally (all actions) or per‑action. To cache only certain actions, add a cache property to the service schema.

   // services/user.service.js
   module.exports = {
     name: 'users',
     actions: {
       // This action will be cached
       async getProfile(ctx) {
         const { userId } = ctx.params;
         // Simulate expensive work
         await new Promise(r => setTimeout(r, 200));
         return { id: userId, name: 'Alice', role: 'admin' };
       }
     },
     // Cache settings for all actions in this service
     cache: {
       ttl: 5000,               // time‑to‑live in milliseconds
       // Use specific params to build the cache key
       keys: ['params.userId']
     }
   };
   

   The keys array tells Moleculer which resolved parameters to include in the generated cache key. You can also provide a custom keyResolver function if your parameters are complex objects.

4. Start (or restart) the service

   After saving the changes, restart your Node process so the broker loads the new configuration.

5. Verify that caching is working

   1. Call the action twice with identical parameters (e.g., userId: 42) using a client, the Moleculer CLI, or a test script.
   2. Check the broker logs. You should see a line similar to cache miss on the first call and cache hit on the second.
   3. Optionally, measure response times; the second call should be noticeably faster.
   4. If you chose Redis, run KEYS moleculer:cache:* in redis-cli after the first call to confirm a key appears, and verify it disappears after the TTL expires.

Expected checks

• Log entries show cache miss for the first invocation and cache hit for subsequent identical calls.
• Response time of the second call is significantly lower than the first (e.g., >50 % reduction).
• When using Redis, the KEYS command lists cache keys that match the pattern moleculer:cache:*.
• Disabling caching (enabled: false) removes the cache hit/miss logs and restores original response times.

Recovery options (rollback)

Enabling caching only changes broker configuration and does not alter persistent data. To revert:

1. Set cache.enabled: false in the broker options or remove the cache property from the service schema.
2. Restart the service.
3. Confirm that log entries no longer contain cache hit or cache miss and that response times return to baseline.

If you experience stale data because the TTL is too high, lower the ttl value or manually invalidate with this.broker.cache.clear('users.getProfile') (replace with your service/action name) after data updates.