T.memoize lifetime cache vs manual Hash TTL for mutable data under memory pressure

Direct Answer

Correctness: Manual Hash with TTL preserves correctness when source data mutates; T.memoize does not unless the receiver is effectively immutable after construction.

Memory growth: T.memoize grows unbounded with the number of distinct receivers that have been memoized. A bounded Hash TTL caps memory at the configured maximum entries.

Invalidation: Yes, explicit invalidation is required for T.memoize whenever business logic changes dependent data. There is no automatic mechanism.

Why This Is the Case

T.memoize semantics (Crystal 1.0+)

• Expands to an instance variable @__memoize_<method> on the receiver.
• The cached value lives as long as the receiver is reachable. The receiver cannot be collected while the memoized value is held.
• No TTL, no size bound, no automatic invalidation. If the source data mutates after the first call, the stale value remains until the receiver is garbage-collected or the instance variable is manually overwritten.

Manual Hash with TTL

• Cache lives at module or class level, keyed by a stable identifier (UUID, DB primary key, not a mutable field).
• Entries expire by time-to-live or are evicted by LRU/LFU policy, bounding memory independently of receiver lifetime.
• Invalidation is explicit: delete the key, update the entry, or bump a version/epoch counter included in the key.

Memory under sustained load

With many short-lived or frequently mutating source objects, T.memoize retains one cached value per distinct receiver that ever called the method. RSS grows linearly with that count. A bounded Hash TTL releases expired/evicted entries for GC, keeping RSS near the configured cap.

Practical Verification Steps

1. Confirm Crystal version: crystal --version (memoize semantics stable since 0.35).
2. Write a minimal benchmark: create N objects with mutable state, call the memoized method, mutate state, observe stale return value and memory via GC.stats or Process.memory.
3. Implement a manual Hash TTL with max-size LRU (e.g., LLVM::OrderedHash or a doubly-linked list) and compare RSS growth under identical load.
4. Review the macro expansion if needed: crystal tool hierarchy --format=dot or inspect the generated instance variable name.

One Missing Detail That Changes the Recommendation

What is the mutation pattern and invalidation trigger? If mutations are rare and tied to a clear event (e.g., explicit save), a manual cache with event-based invalidation is simpler than TTL. If mutations are frequent and unpredictable, TTL (or a version counter on the source) is safer. Answering this lets you choose between event-driven invalidation, TTL, or a hybrid.