application-caching

Record a justification and staleness budget in a cache register, derive the key from every input that varies the value including the tenant, set a TTL at or below the budget, and cache immutable domain objects at the service boundary rather than entities.

The eviction runs before the commit, so a concurrent reader can repopulate the cache with the pre-write row, leaving a permanently stale entry. Trigger invalidation after commit via a transactional event listener or a transaction-aware cache manager.

Local caches like Caffeine suit small, slowly changing data with an approved staleness window. Distributed stores like Redis earn their network hop when entries must be consistent across instances, survive restarts, or are expensive to compute.

The key must contain every input that changes the result, including the tenant identifier and, when the value is filtered by authorization, the calling subject. Omitting the tenant serves one tenant's data to another.

Only after the project profile records a cache decision, with a staleness budget and a chosen concurrency strategy. The query cache is usually wrong because any write to touched tables invalidates it, giving a near-zero hit ratio on mutable data.

A cache never fixes an N+1 query, missing index, or unbounded read; it hides the defect and adds staleness. Fix the query first, then cache only with a structural or measured justification.