When does Moleculer's built-in cacher invalidate entries after the underlying data changes?
0 reputation · 12 Jul 2023, 02:20 UTC
I'm designing a Moleculer service where several actions are wrapped with the built-in cacher, and I'm trying to pin down exactly when a cached action response stops being served. Assume a recent Moleculer 0.14.x release with the default in-memory cacher.
My understanding is that the cacher keys entries from the action name plus params, and that a TTL controls expiry. What is unclear to me is the relationship between TTL-based expiry and explicit invalidation: if the underlying data store is updated through a different service (or outside the broker entirely), does the cacher have any mechanism to notice, or does it keep serving the old response until the TTL elapses or a manual clean occurs?
I also see references to cache invalidation via events and to wildcard key cleaning, but the documented behavior around which keys get cleared, and whether that differs between the memory cacher and a distributed backend like Redis, is ambiguous to me.
- Does Moleculer's cacher invalidate entries only via TTL and explicit
cacher.cleancalls, or is there any automatic reaction to data changes? - When broadcasting a cache-clear event, how are wildcard keys matched against the generated cache keys?
- Does invalidation behavior differ between the built-in memory cacher and the Redis cacher in a multi-node setup?