Spring Boot Caching: @Cacheable, @CacheEvict, and Redis

Caching reduces database load and cuts response times significantly. Spring Boot makes caching accessible through its annotation model, but that simplicity hides depth. Get the fundamentals wrong and you will spend weeks chasing stale data bugs and production outages.

This guide walks through Spring Boot caching from the ground up. You will learn when caching genuinely helps versus when it adds complexity you do not need, see the annotated patterns that matter in practice, understand the failure modes that send engineers to production at 2 AM, and pick up the observability habits that separate teams who debug cache issues quickly from those who cannot. If you are working through the Spring Boot learning path, this post fits between the fundamentals and the advanced microservices patterns.

Introduction to Spring Boot Caching

Introduction

Spring Boot caching stores frequently requested results so applications can reduce database work and respond faster. This guide explains how @Cacheable, @CacheEvict, and related annotations behave, when Redis is appropriate, and how to reason about cache misses, invalidation, consistency, and failure scenarios.

When to Use and When to Avoid Caching

Caching earns its place when three conditions hold simultaneously: the same data gets requested frequently, the computation or database query behind it is expensive, and the data changes infrequently relative to how often it gets read. User profiles, product catalogs, configuration lookups, and reference data all fit this pattern naturally. The moment you apply caching to data that changes every few seconds, you inherit a stale-data problem that can silently corrupt user experiences in ways that are devilish to reproduce and diagnose.

What people underestimate is cache invalidation. Two strategies compete. Time-based expiration (TTL) is simple to implement and guarantees eventual consistency, but it trades freshness for staleness. Active invalidation through @CacheEvict gives you point-in-time correctness, but it requires you to identify every code path that modifies data and wire the eviction correctly. Miss a single update path and you serve stale data until the TTL expires. Caching shines brightest with read-heavy data that has clear, enumerated write paths. It becomes a liability when writes are frequent and scattered across many services.

Skip caching when your application is write-heavy with short retention windows, when data must always reflect the absolute latest state (financial transactions, inventory counts), or when your cache infrastructure would cost more to operate than simply scaling the database. Only cache when you have measured that the performance gain justifies the consistency tradeoff.

graph TD
    A[Request arrives] --> B{Cache lookup}
    B -->|Hit| C[Return cached value]
    B -->|Miss| D[Execute method]
    D --> E[Store result in cache]
    E --> F[Return result]
    C --> G[(Cache)]
    F --> G
    H[Write operation] --> I{Cache eviction}
    I --> J[Remove from cache]
    J --> G

Failure Scenarios

Stale Data

Stale data occurs when the cache reflects a state that no longer matches the database. This happens whenever data changes without a corresponding eviction. Imagine a user updates their email address. If the profile service writes to the database but your caching layer does not receive the eviction event, the next read returns the old email. The result ranges from minor annoyance to serious business impact (incorrect reports, compliance issues). Mitigations include active invalidation on all write paths, reasonable TTL values as a safety net, and monitoring that alerts when cache hit rates spike unexpectedly.

Cache Penetration

Cache penetration happens when requests repeatedly query for non-existent data. Each request bypasses the cache because the key does not exist, then hits the database. Enough of these arriving simultaneously can overwhelm your database with queries for keys that will never match. The standard defense is to cache negative results. When a database query returns null, store a sentinel value in the cache with a short TTL. Repeated queries for the same non-existent key return quickly from the cache instead of hammering the database.

Cache Avalanche

Cache avalanche occurs when a large number of keys expire simultaneously and a spike of requests all miss the cache at once, flooding the backend. This commonly happens when you set identical TTL values on many entries during a deployment or when a cache node restarts and its contents are lost. Suddenly thousands of requests call the database simultaneously because none of them find a cached value. Preventing this requires randomizing TTL values so keys do not expire in lockstep, pre-warming the cache after restarts, and implementing request coalescing so that only one request per key triggers the backend fetch.

Trade-off Table: In-Memory vs Redis vs Memcached

For a single-instance Spring Boot service with modest cache needs, in-memory caching with Caffeine is the simplest path. Once you scale horizontally across multiple application instances, Redis becomes essential because it provides a shared, consistent view of cached data across all nodes. Memcached works for simple distributed blob caching, but Redis has taken over most of its use cases in Spring Boot ecosystems due to richer data structures and better tooling. For a full overview of distributed systems patterns including caching strategies, see the distributed systems roadmap.

Implementation

Enabling Caching

The entry point is @EnableCaching on any @Configuration class. This activates Spring’s CachingInterceptor and registers the cache advisors that power the annotations.

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Configuration;

@Configuration
@EnableCaching
public class CacheConfig {
}

Basic @Cacheable

The @Cacheable annotation marks methods whose results should be cached. By default, the cache name comes from the value or cacheNames attribute, and the cache key is derived from all method arguments.

import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    @Cacheable(cacheNames = "products", key = "#productId")
    public Product getProduct(Long productId) {
        System.out.println("Fetching product from database: " + productId);
        return productRepository.findById(productId).orElseThrow();
    }
}

Cache Eviction

@CacheEvict removes entries when data changes. Use allEntries = true to clear the entire cache, or specify a key to remove a single entry.

import org.springframework.cache.annotation.CacheEvict;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    @CacheEvict(cacheNames = "products", allEntries = true)
    public void refreshAllProducts() {
        // This clears the entire "products" cache
    }

    @CacheEvict(cacheNames = "products", key = "#productId")
    public void updateProduct(Long productId, Product product) {
        productRepository.save(product);
        // Only the specific productId entry is evicted
    }
}

Write-Through with @CachePut

@CachePut always executes the method and updates the cache with the result. Use this when you want to cache the result of an update operation so subsequent reads get the fresh data without a separate eviction call.

import org.springframework.cache.annotation.CachePut;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    @CachePut(cacheNames = "products", key = "#result.id")
    public Product updateProduct(Long productId, Product product) {
        Product saved = productRepository.save(product);
        return saved;  // Cache is updated with the returned product
    }
}

Class-Level Configuration with @CacheConfig

When multiple methods in a class share the same cache configuration, @CacheConfig keeps things DRY.

import org.springframework.cache.annotation.CacheConfig;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.stereotype.Service;

@Service
@CacheConfig(cacheNames = "products")
public class ProductService {

    @Cacheable
    public Product getProduct(Long productId) {
        return productRepository.findById(productId).orElseThrow();
    }

    @CacheEvict(key = "#productId")
    public void deleteProduct(Long productId) {
        productRepository.deleteById(productId);
    }
}

Redis Configuration

Spring Boot auto-configures a RedisCacheManager when Redis is on the classpath and spring.cache.redis.* properties are set. The YAML below sets per-cache TTL values.

spring:
  cache:
    type: redis
    cache-names: products, categories, users
    redis:
      time-to-live: 10m
      cache-null-values: false
  data:
    redis:
      host: localhost
      port: 6379
      password:

For more control over serialization strategy, define a RedisCacheConfiguration bean.

import org.springframework.cache.CacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.StringRedisSerializer;
import java.time.Duration;

@Configuration
public class RedisCacheConfig {

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(10))
            .serializeKeysWith(
                RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())
            )
            .serializeValuesWith(
                RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())
            )
            .disableCachingNullValues();

        return org.springframework.data.redis.cache.RedisCacheManager.builder(connectionFactory)
            .cacheDefaults(config)
            .withInitialCacheConfigurations(java.util.Map.of(
                "products", config.entryTtl(Duration.ofMinutes(30)),
                "users", config.entryTtl(Duration.ofMinutes(5))
            ))
            .build();
    }
}

Cache Key Generation

Spring uses a KeyGenerator to create cache keys from method parameters. The default strategy concatenates the bean class name, method name, and parameter values. For cleaner keys, use SpEL expressions in the key attribute.

// Default key generation: productService.getProduct(42) -> "productService.getProduct(42)"

// Custom key with SpEL
@Cacheable(cacheNames = "products", key = "#productId")
public Product getProduct(Long productId) { ... }

// Composite key
@Cacheable(cacheNames = "products", key = "#category + ':' + #page")
public List<Product> getProductsByCategory(String category, int page) { ... }

// Custom KeyGenerator bean
@Bean
public KeyGenerator productKeyGenerator() {
    return (target, method, params) -> {
        StringBuilder builder = new StringBuilder();
        builder.append(target.getClass().getSimpleName());
        builder.append(".").append(method.getName());
        for (Object param : params) {
            builder.append(":").append(param.toString());
        }
        return builder.toString();
    };
}

Observability Checklist

Cache behavior directly impacts application reliability. Build these observability practices into your caching implementation from day one.

• Log cache hit/miss rates at the application level. Most cache providers expose metrics through JMX or Micrometer. Track cache hit ratio as a percentage, and alert when it drops below a threshold that makes caching economically sensible.
• Monitor cache size and eviction frequency. A cache that grows without bound indicates a TTL or size limit problem. High eviction rates relative to cache size suggest your cache is too small for the working set.
• Track latency percentiles with and without cache. Cache hits should be sub-millisecond. If cache hits are slow, investigate serialization overhead or network latency to the cache store.
• Alert on error rates from the cache layer. Connection timeouts, serialization failures, and rejected writes all surface as exceptions. Route these to your alerting system.
• Log eviction events for significant keys. When a cache entry is evicted due to expiration or explicit invalidation, log the key name and eviction reason. This makes post-mortem analysis tractable.
• Correlate cache metrics with business metrics. If your checkout conversion rate drops and your cache miss rate spikes simultaneously, you have a causality link that points directly at the cache layer.
• Instrument cache key generation failures. Key generation that throws exceptions will silently bypass the cache and flood your backend. Monitor for these error patterns.

Security Notes

Sensitive Data in Cache

Caching sensitive data requires the same access controls you apply to the database. If you cache user personal information, payment details, or credentials, that data now lives in an additional store that must be encrypted at rest, encrypted in transit, and subject to access auditing. In multi-tenant environments, verify that cache isolation is sufficient to prevent tenant A from accessing tenant B’s cached data through key collision or shared infrastructure. The practical rule: never cache sensitive data unless you have a specific performance requirement that demands it and a security architecture that actually protects it.

Cache Poisoning

Cache poisoning happens when someone manipulates the data that gets stored in your cache. If your application fetches data from an external API or user-supplied source and caches it without validation, a malicious actor who controls that source can inject invalid, malicious, or inappropriate content. Subsequent users who request that data receive the poisoned content. Defenses include validating all data before caching, using input sanitization at cache write time, and applying content security policies that limit what cached data can do when rendered.

Common Pitfalls / Anti-Patterns

Serialization Issues

Redis and Memcached require objects to be serialized to bytes for storage. The default Java serialization is convenient but fragile: if you change a class structure (add fields, rename fields, change types), cached objects from previous versions will fail to deserialize. Use a stable serialization format like JSON (through GenericJackson2JsonRedisSerializer or Jackson2JsonRedisSerializer) or Protocol Buffers. JSON is human-readable during debugging, which is a practical advantage over binary formats. If you are working with API responses that need consistent serialization, the API contracts post covers related versioning strategies.

Key Collisions

If two different methods in different services share the same cache name and key format, they can overwrite each other’s entries. A product.getProduct(1) in the product service and order.getProduct(1) in the order service would collide if both use cacheNames = “products” and a key derived only from the ID. Scope your cache names to the service: cacheNames = “productServiceProducts” or use namespaced keys.

Cache Stampede

Also called the thundering herd problem. When a popular cache entry expires or a cache node fails, requests simultaneously discover the cache miss and all hit the backend database at once. The solution is request coalescing: when multiple threads request the same key simultaneously, only one thread fetches from the database while the others wait. Spring Boot does not provide this out of the box, but Caffeine or Redis-based solutions like Redisson provide cache stampede protection through distributed locks or synchronized loading patterns.

Production Failure Scenarios

Cache failures do not always look like cache failures. The symptoms often surface as database timeouts or mysterious data inconsistencies.

Stale Data Causing Business Logic Errors

Caching data that changes frequently produces stale reads. A user updates their profile, the write succeeds, but subsequent reads return the old data until the TTL expires. In reporting or billing contexts, this can produce incorrect results that pass validation because the data looks valid in isolation. The fix is active invalidation on every write path that touches the underlying data. TTL values act as a safety net, not a correctness mechanism. If writes are frequent and scattered across multiple services, caching may not be the right tool.

Cache Penetration Exhausting Database Under Load

An attacker or a bug sends requests for keys that do not exist, over and over. Each request bypasses the cache because the key is absent, hits the database, and returns nothing. At scale, this hammers the database with queries for keys that will never match. The standard fix is caching negative results: when a query returns null, store a sentinel value with a short TTL rather than nothing. Repeated requests for the same absent key return from the cache without touching the database.

Cache Stampede Causing Thundering Herd

When a high-traffic cache entry expires simultaneously or a cache node fails, all requests that would have hit that entry miss at once. Without cache stampede protection, each miss fires a backend query simultaneously, overwhelming the database with duplicate requests for the same data. Request coalescing solves this: when multiple threads request the same key at the same time, only one thread fetches from the backend and the others wait for that result. Caffeine’s LoadingCache and Redis-based solutions with lock-based loading all provide this protection.

Serialization Failure After Class Structure Changes

Changing a Java class that has cached instances in Redis or Memcached causes deserialization to fail. A field is renamed, a type is changed, or a class is removed. The old serialized bytes can no longer be parsed by the new class definition. The result is a cache full of unusable entries and a spike in cache misses that hit the database. Avoid Java default serialization for cached objects. Use stable formats like JSON through GenericJackson2JsonRedisSerializer or Protocol Buffers. Include version information in cached objects so migration strategies can detect and handle older formats.

Quick Recap Checklist

• Add @EnableCaching to your configuration class before using any caching annotations.
• Use @Cacheable for read operations where the same inputs repeatedly produce the same outputs.
• Use @CacheEvict on every write path that modifies data backing a cache.
• Use @CachePut when you want to update cached data on writes without a separate eviction call.
• Set reasonable TTL values as a safety net even when you use active invalidation.
• Choose in-memory caching for single-instance applications, Redis for distributed systems.
• Configure serialization explicitly. Do not rely on default Java serialization for production data.
• Monitor cache hit rate, latency percentiles, and eviction counts.
• Never cache sensitive data without evaluating the security implications.
• Implement cache stampede protection for high-traffic, high-value cache entries.
• Use scoped cache names to prevent key collisions across services.

Interview Questions

Further Reading

• Spring Boot Cache Documentation - Official Spring Boot caching reference
• Spring Cache Abstraction Guide - Deep dive into Spring’s caching annotations
• Redis Cache Configuration - Spring Data Redis cache specifics
• Caffeine Cache - High-performance in-memory caching library
• Spring Boot Learning Path - Complete learning path for Spring Boot

Conclusion

Spring Boot’s caching annotations provide a powerful and flexible abstraction for reducing database load and improving response times, but that simplicity requires discipline to avoid subtle production bugs. The annotation model handles the happy path well, but cache invalidation, TTL management, and serialization strategy demand careful attention.

The most important principles to carry forward: cache invalidation must be explicit and cover every write path, TTL values serve as a safety net rather than a correctness mechanism, and serialization choices must anticipate class evolution. For single-instance applications, in-memory caching with Caffeine provides the simplest path to performance gains. For distributed systems, Redis delivers shared state and persistence at the cost of network round-trips and serialization complexity.

Monitoring cache behavior in production is non-negotiable. Track hit rates, eviction counts, and latency distributions for cache operations. Alert on deviations that suggest stale data serving or cache exhaustion. When done well, caching is invisible to callers and delivers consistent performance gains. When done poorly, it surfaces as mysterious data inconsistencies and production incidents that are difficult to diagnose.