Spring Boot Caching

No. With only spring-boot-starter-cache, Spring Boot uses a simple cache built on ConcurrentHashMap, and caching works right away.

That default is fine for learning and small tools, but not for production: entries never expire and the cache has no size limit, so it can serve stale data and keep growing until memory runs out. Use Caffeine or Redis for real applications.

Go through this checklist:

1. @EnableCaching is missing. Without it, the annotations are ignored.
2. The method is called from the same class. Internal calls skip the Spring proxy, so no caching happens.
3. The method is private. Proxies can only intercept methods that can be called from outside the class.
4. The key changes on every call, for example an object argument without proper equals() and hashCode(), or a timestamp parameter.
5. Caching is switched off with spring.cache.type=none in the active profile.
6. An unless or condition expression excludes the call.

They produce the same keys. If both methods take a single Long id and share the products cache, they write to the same entries:

@Cacheable("products")
public ProductDto getProduct(Long id) { ... }

@Cacheable("products")                       // same cache, same key: 7
public List<ReviewDto> getReviews(Long id) { ... }

Calling getReviews(7) may now return a ProductDto, causing a ClassCastException or wrong output. The simplest fix is to give each method its own cache name, such as products and productReviews.

Most providers cache null by default, so a “not found” result is remembered even after the record is created. Skip it with unless:

@Cacheable(value = "customers", unless = "#result == null")
public CustomerDto findByEmail(String email) {
    return customerRepository.findByEmail(email).map(CustomerDto::from).orElse(null);
}

Methods that return Optional work too. Spring unwraps the Optional, so #result refers to the value inside it. For Redis, you can also disable null caching for all caches with RedisCacheConfiguration.defaultCacheConfig().disableCachingNullValues().

Set a maximum size so old entries are removed when the limit is reached. With Caffeine:

spring.cache.caffeine.spec=maximumSize=5000,expireAfterAccess=30m

Size the limit by memory, not just count: 5,000 small records are fine, but 5,000 large reports may not be. For Redis, set a memory limit and eviction policy on the server itself, for example maxmemory 512mb and maxmemory-policy allkeys-lru.

Yes. Register custom caches with a CacheManagerCustomizer:

@Bean
public CacheManagerCustomizer<CaffeineCacheManager> caffeineCustomizer() {
    return manager -> {
        manager.registerCustomCache("exchangeRates",
                Caffeine.newBuilder().expireAfterWrite(Duration.ofMinutes(1)).build());
        manager.registerCustomCache("countries",
                Caffeine.newBuilder().maximumSize(300).expireAfterWrite(Duration.ofDays(1)).build());
    };
}

Caches not registered here still use the shared spring.cache.caffeine.spec settings.

Redis stores bytes, and by default Spring uses Java serialization. Any cached class that does not implement Serializable, or contains a field that does not, fails to convert.

• Quick fix: make the cached class, and every class inside it, implement Serializable.
• Better long-term fix: configure a JSON serializer in RedisCacheConfiguration with serializeValuesWith(...). JSON is readable in Redis tools and does not break when a class gains a new field.

Also remember that after you change a cached class, old entries in Redis may no longer match it. Clear the affected caches when you deploy such changes.

A stampede happens when a popular entry expires and hundreds of requests miss the cache at the same moment. All of them run the slow query together, and the database can be overwhelmed.

Ways to prevent it:

• @Cacheable(sync = true), so only one thread per instance loads the value while the others wait.
• Refresh before expiry. Caffeine’s refreshAfterWrite reloads the entry in the background while still serving the old value.
• Add some randomness to expiry times so many entries do not expire together.

It is better to cache DTOs or records instead. Entities cause several problems in a cache:

• Lazy relationships fail with LazyInitializationException when accessed after the original transaction has closed.
• Entities are mutable. If code changes a cached entity, every later reader sees the change, even though it was never saved.
• They can be large, pulling in related objects you did not mean to cache.

Convert the entity to a small, read-only record before returning it from the cached method, as ProductDto does in this tutorial.

Inject the CacheManager and clear every cache it knows:

@Service
public class CacheAdminService {

    private final CacheManager cacheManager;

    public CacheAdminService(CacheManager cacheManager) {
        this.cacheManager = cacheManager;
    }

    public void clearAll() {
        cacheManager.getCacheNames().forEach(name -> {
            Cache cache = cacheManager.getCache(name);
            if (cache != null) {
                cache.clear();
            }
        });
    }
}

With Actuator, you can also send DELETE /actuator/caches to clear everything, or DELETE /actuator/caches/products for one cache. Secure these endpoints, since anyone who can call them can slow down your app.

Set the cache type to none in the profile or test where you want it off:

spring.cache.type=none

Your annotations stay in place, but every call goes straight to the method. This is useful when debugging, or for tests that check business logic and should not be affected by results left over from earlier tests.

It works, but the service layer is usually the better place. Service methods are reused by controllers, scheduled jobs and message listeners, so all of them benefit from the cache.

Do not confuse server-side caching with HTTP caching. If you want browsers or CDNs to keep a response, set response headers instead:

@GetMapping("/{id}")
public ResponseEntity<ProductDto> get(@PathVariable Long id) {
    return ResponseEntity.ok()
            .cacheControl(CacheControl.maxAge(Duration.ofMinutes(5)).cachePublic())
            .body(productService.getProduct(id));
}

The two work well together: the server cache avoids repeated database work, and HTTP caching avoids repeated requests.

Yes, but watch for one trap: cache updates are not part of the database transaction by default. If a @CachePut method stores a value and the transaction then rolls back, the cache holds data that was never saved.

Two solutions:

• Prefer @CacheEvict on write methods. A removed entry is simply reloaded later, so a rollback cannot leave wrong data behind.
• Make the cache manager transaction-aware, so puts and evictions happen only after a successful commit. For example, call transactionAware() on the Redis cache manager builder, or wrap any cache manager in TransactionAwareCacheManagerProxy.

Yes. Define both beans, mark one as @Primary, and choose the other per method with the cacheManager attribute:

@Configuration
@EnableCaching
public class MultiCacheConfig {

    @Bean
    @Primary
    public CacheManager localCacheManager() {
        CaffeineCacheManager manager = new CaffeineCacheManager();
        manager.setCaffeine(Caffeine.newBuilder().maximumSize(1000).expireAfterWrite(Duration.ofMinutes(5)));
        return manager;
    }

    @Bean
    public CacheManager sharedCacheManager(RedisConnectionFactory connectionFactory) {
        return RedisCacheManager.builder(connectionFactory).build();
    }
}

@Cacheable(value = "sessions", cacheManager = "sharedCacheManager")
public SessionDto getSession(String token) { ... }

• Optional: yes. Spring stores the value inside it, and wraps it in an Optional again when returning from the cache.
• CompletableFuture and reactive types (Mono, Flux): supported since Spring Framework 6.1, but only with a cache that supports asynchronous access. With Caffeine, enable it on the cache manager:

@Bean
public CacheManagerCustomizer<CaffeineCacheManager> asyncCaffeine() {
    return manager -> manager.setAsyncCacheMode(true);
}

On older Spring versions, cache the plain value inside the asynchronous flow instead.

Call the cached methods once the application is ready. The results then go into the cache before the first user arrives:

@Component
public class CacheWarmer {

    private final CategoryService categoryService;

    public CacheWarmer(CategoryService categoryService) {
        this.categoryService = categoryService;
    }

    @EventListener(ApplicationReadyEvent.class)
    public void warmUp() {
        categoryService.getAllCategories(); // @Cacheable, now stored in the cache
    }
}

Keep warm-up small and focused on the most-used data, so startup stays fast.

With an in-memory cache, each instance has its own copy. An update handled by instance A evicts the entry only on A, so B and C keep serving the old value. Options:

1. Use a shared cache such as Redis, so there is only one copy.
2. Use short expiry times for in-memory caches, so stale data disappears quickly.
3. Broadcast evictions with a message, for example through Redis pub/sub or Kafka, so every instance removes the entry.

Option 1 is the simplest. Options 2 and 3 suit cases where local caching speed matters most.

When freshness matters, use expireAfterWrite. expireAfterAccess alone can keep a frequently read entry indefinitely, even after the source data has changed.

Include the user in the cache key, so users never see each other’s data:

@Cacheable(value = "recommendations", key = "#userId + ':' + #category")
public List<ProductDto> recommendationsFor(Long userId, String category) {
    // ...
}

Avoid relying on hidden context, such as reading the current user inside the method without passing it in. The key would then ignore the user, and one person’s result could be served to everyone. Also think twice before caching sensitive personal data in a shared cache.

Ask: how old can this data be before it causes a problem?

Start conservative, then use your hit-ratio metrics to adjust. Remember that eviction on writes keeps data fresh within one instance, so expiry mainly protects against changes made outside your application.