Caching: keys, freshness and invalidation
Prerequisites: 01-ecosystem
What happens on a cache hit and miss?
Goal & mental model verified
Spring’s cache abstraction delegates storage to a backing implementation. @Cacheable can reuse results; eviction and updates define freshness behavior. An annotation alone does not define TTL or make a distributed cache consistent.
[S36] [S37]Worked example · design exercise synthesis
For a policy summary, use a key containing tenant and policy ID. Evict or update affected summaries after successful policy changes under an explicitly chosen consistency policy.
[S36] [S37]Engineering decision synthesis
Cache expensive, repeatedly read data with an acceptable staleness budget. Choose local versus shared storage by consistency, footprint and latency requirements.
[S36] [S37]Pitfall & diagnosis synthesis
Missing tenant identity in a key can reuse another tenant’s data. Default proxy-based caching also has self-invocation limits. Cache invalidation and database commit ordering need care.
[S36] [S37]Improve & validate synthesis
Measure hit ratio, stale reads and miss cost. Exercise concurrent misses and updates; bound entry size and TTL using the provider’s configuration.
[S36] [S37]Check yourself: Does @Cacheable itself choose a TTL?
No. Expiration is generally a backing-cache/provider concern.