cache
Caching
Ask first: which store
This is the first question, before any code, because it is the one that is expensive to change later — it decides whether invalidation is correct on one node or on all of them.
| Option | Right when |
|---|---|
InMemoryCache |
One instance serves the traffic, or the data is cheap to recompute and staleness across nodes is harmless |
LettuceCache (Redis) |
More than one instance serves the same traffic and a write on one must be visible to the others |
Custom KeyValueCache |
You already run a different store, or entries need behaviour the two above do not have |
If the user is unsure, ask one question: how many instances run in production? More than one and the answer is Redis. With InMemoryCache behind
a load balancer, each instance holds its own copy and invalidateNamespace only clears the node that handled the write — the other nodes keep serving
stale data until their TTL expires. That is not a subtle bug, but it is invisible in development, where there is only ever one instance.
If the answer is genuinely one instance today and more later, InMemoryCache now is fine: both implement KeyValueCache, so the swap is a line in
the DI wiring. Say that out loud so the decision is recorded rather than forgotten.