When does Moleculer's built-in cacher invalidate entries after the underlying data changes?

Answer – First: When does a cached entry stop being served?

In Moleculer 0.14.x the built‑in cacher removes a cached action result only when one of the following happens:

• TTL expiry – the key’s time‑to‑live runs out.
• Explicit clean – the service calls this.broker.cacher.clean(key) or a clear event is broadcast.
• Manual cacher.clean() call without a key (clears all entries).

There is no automatic invalidation that listens to changes in an external data store. If another service updates the data, the cacher will keep returning the old response until one of the above mechanisms triggers.

How cache‑clear events work

When a service emits an event like cache.clear, the broker distributes it to all nodes. Each node’s cacher receives the event and deletes every key that matches the supplied pattern. The pattern is a simple glob – * matches any sequence of characters, ? matches a single character. It is not a regular expression.

Example:

this.broker.emit('cache.clear', 'user.*');

All keys that start with user. will be removed. Wildcard matching is performed by the cacher implementation, so the same syntax applies to both the in‑memory and Redis backends.

Memory vs Redis in a multi‑node environment

• Memory cacher – each node has its own isolated cache. A clear event on node A removes keys only from node A’s cache; node B will continue to serve stale values until its own TTL or clean occurs.
• Redis cacher – all nodes share the same Redis store. A clean command issued on any node deletes the key from the Redis database, so every node sees the updated state immediately (subject to network latency).

Practical steps for your use case

1. Set a reasonable ttl (e.g., 60 s) on the action that reads the data.
2. When the data‑updating service changes a record, have it emit('cache.clear', 'actionName.*') where actionName is the cached action’s name.
3. If you use the memory cacher and run multiple broker instances, remember that the clear event will only affect the local cache; you’ll need to emit the event from every node or switch to Redis for shared caching.
4. Optionally, add a fallback: if the cached result is stale, the action can detect it (e.g., by checking a version field) and force a refresh.

What you still need to confirm

Do you already set a ttl on the cached actions? If not, the entries will never expire automatically. If you rely on the default (no TTL), you must use explicit clean or events to keep the cache fresh.