# TTL and size bounds are the provider's job, not the abstraction's

cacheManager : org.springframework.cache.caffeine.CaffeineCacheManager
configured   : expireAfterWrite=400ms, maximumSize=3, recordStats

two calls, same key, immediately -> 1 repository calls
one more call 600 ms later      -> 2 repository calls   <- the entry expired

--- size bound ---
five distinct keys written, maximumSize = 3
estimated size after eviction settles : 3
stats                                 : hits=1 misses=5 evictions=3

--- recordStats is not on by default ---
a Caffeine cache built without recordStats(), after 1 hit and 1 miss:
  CacheStats{hitCount=0, missCount=0, loadSuccessCount=0, loadFailureCount=0, totalLoadTime=0, evictionCount=0, evictionWeight=0}

Every counter is zero. Micrometer's cache.gets and cache.evictions will
exist and report zero too, which looks exactly like a cache nobody uses.

The Spring cache abstraction has no TTL, no size limit and no eviction
policy of its own - it is an interface over whatever you plug in. On the
default simple provider, a ConcurrentHashMap, an entry stays until something
evicts it by hand or the process ends.