Missing @Cacheable — 40x Latency Spike in Spring Boot Redis

In a Spring Boot 3.2 application using Redis as a cache backend, a single missing @Cacheable annotation can turn a sub-5ms response into a 200ms+ nightmare under production load. I've seen this exact scenario bring down a payment-processing pipeline during Black Friday, where a 40x latency spike caused cascading timeouts and a 15-minute outage. The root cause? A developer added caching to the repository layer but forgot to annotate the service method that actually called it. Spring's cache abstraction works at the proxy level — if the method isn't intercepted by the cache aspect, you get zero caching. This tutorial walks through a realistic incident in a SaaS billing system, showing how to diagnose, fix, and prevent this issue with Spring Boot 3.2 and Redis 7.0. You'll learn how to use Spring Boot Actuator's cache metrics, Redis's built-in monitoring, and proper AOP-based caching patterns. By the end, you'll be able to spot cache-miss storms before they hit production.

How @Cacheable Works in Spring Boot 3.2 with Redis

Spring's cache abstraction is built on AOP proxies. When you annotate a method with @Cacheable, Spring creates a proxy around the bean. On invocation, the proxy checks the cache (Redis) before executing the method body. If a cache hit occurs, the method body is skipped entirely, returning the cached value. If a cache miss, the method runs, and the result is stored in Redis for future calls. This works seamlessly with Redis via spring-boot-starter-data-redis, which auto-configures a RedisCacheManager with default TTL and serialization. However, the proxy only intercepts calls from outside the bean. Internal calls (self-invocation) bypass the proxy entirely, which is the root cause of the missing cache scenario. In Spring Boot 3.2, you can also use @CachePut to update cache without skipping method execution, and @CacheEvict to invalidate entries. The key takeaway: caching is not transparent — you must ensure the method is called through the proxy.

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

@Service
public class InvoiceService {

    private final InvoiceRepository invoiceRepository;

    public InvoiceService(InvoiceRepository invoiceRepository) {
        this.invoiceRepository = invoiceRepository;
    }

    @Cacheable(value = "invoices", key = "#id")
    public Invoice getInvoiceById(Long id) {
        // This method body only executes on cache miss
        return invoiceRepository.findById(id)
                .orElseThrow(() -> new InvoiceNotFoundException(id));
    }
}

What the Official Docs Won't Tell You

Spring's official documentation covers @Cacheable basics but glosses over three critical gotchas. First, self-invocation: if method A in the same class calls method B annotated with @Cacheable, the cache aspect is NOT applied. This is because Spring creates a JDK dynamic proxy (or CGLIB proxy) that wraps the bean, but internal calls use 'this' reference, skipping the proxy. Second, the default cache key generation uses SimpleKeyGenerator which includes all method parameters — if you have multiple parameters, the key becomes complex and can cause collisions or misses. Always specify a custom key with SpEL. Third, the default Redis serialization uses JdkSerializationRedisSerializer which is slow and not human-readable. Switch to Jackson2JsonRedisSerializer for better performance and debuggability. In production, I've seen teams waste hours debugging cache misses only to find they were using default serialization with incompatible class versions after a deployment. The fix: configure a custom RedisCacheConfiguration with JSON serialization and explicit TTL.

import org.springframework.cache.annotation.EnableCaching;
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 java.time.Duration;

@Configuration
@EnableCaching
public class RedisConfig {

    @Bean
    public RedisCacheConfiguration cacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(10))
                .disableCachingNullValues()
                .serializeValuesWith(
                        RedisSerializationContext.SerializationPair
                                .fromSerializer(new GenericJackson2JsonRedisSerializer())
                );
    }
}

Simulating the 40x Latency Spike

Let's reproduce the incident in a controlled environment. We'll create a Spring Boot 3.2 app with Redis, then intentionally omit @Cacheable on the service method. Under load with 100 concurrent requests using Apache JMeter or wrk, observe the latency difference. Without caching, each request hits the database (simulated with Thread.sleep(200) to mimic a slow query). With caching, the first request takes 200ms, subsequent ones take ~2ms (Redis in-memory). That's a 100x difference, but in real scenarios with network overhead and serialization, it's typically 40x. The key metric is the 'cache miss ratio' from Redis INFO stats: 'keyspace_misses' vs 'keyspace_hits'. A miss ratio above 20% under load is a red flag. In our simulation, without @Cacheable, every request is a miss, driving the ratio to 100%. The database connection pool saturates, causing timeouts and cascading failures. This is exactly what happened in the Black Friday incident — the payment pipeline's database pool of 50 connections was exhausted within seconds.

import org.springframework.stereotype.Service;

@Service
public class InvoiceServiceWithoutCache {

    private final InvoiceRepository invoiceRepository;

    public InvoiceServiceWithoutCache(InvoiceRepository invoiceRepository) {
        this.invoiceRepository = invoiceRepository;
    }

    // @Cacheable intentionally missing — this causes the latency spike
    public Invoice getInvoiceById(Long id) {
        // Simulate slow database query
        try {
            Thread.sleep(200);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return invoiceRepository.findById(id)
                .orElseThrow(() -> new InvoiceNotFoundException(id));
    }
}

Diagnosing Cache Misses with Actuator and Redis CLI

Spring Boot Actuator provides a /actuator/cache endpoint that shows cache names and their current statistics. Enable it with 'management.endpoints.web.exposure.include=cache' in application.properties. This endpoint lists all caches defined by @Cacheable annotations and their hit/miss counts. However, it only shows caches that have been accessed at least once. If your @Cacheable annotation is missing entirely, the cache won't appear in the list — that's your first clue. For deeper diagnostics, use Redis CLI: 'INFO stats' shows 'keyspace_hits' and 'keyspace_misses' globally. 'INFO commandstats' shows how many GET commands were executed. A high number of GETs with low hits indicates cache misses. Additionally, enable Redis slow log with 'CONFIG SET slowlog-log-slower-than 10000' to capture slow operations. In the incident, the team saw zero entries in /actuator/cache for 'invoices', which immediately pointed to a missing annotation. They then used Redis CLI to confirm zero cache hits for the invoice keyspace.

management.endpoints.web.exposure.include=health,info,cache,metrics
spring.cache.redis.time-to-live=600000
spring.cache.redis.cache-null-values=false
spring.cache.type=redis

Fixing the Missing @Cacheable with Proper AOP Proxy Usage

The fix involves three steps. First, add @Cacheable with explicit key and cache name to the service method. Second, ensure the method is called from outside the class to hit the AOP proxy. Avoid self-invocation by injecting the service into itself using @Resource (circular reference hack) or by extracting the cached method into a separate bean. Third, verify with load testing that cache hits increase. In Spring Boot 3.2, you can also use @CacheConfig at the class level to define default cache name and key generator. For the self-invocation problem, the cleanest solution is to create a dedicated caching service bean that handles all cached operations. The main service then injects this caching service. This ensures every call goes through the proxy. Alternatively, use AspectJ weaving (compile-time or load-time) which doesn't have the proxy limitation, but that's heavier and less common. In the incident, the team created a 'InvoiceCacheService' bean and injected it into the main service. Latency dropped back to 5ms immediately after deployment.

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

@Service
public class InvoiceCacheService {

    private final InvoiceRepository invoiceRepository;

    public InvoiceCacheService(InvoiceRepository invoiceRepository) {
        this.invoiceRepository = invoiceRepository;
    }

    @Cacheable(value = "invoices", key = "#id")
    public Invoice getInvoiceById(Long id) {
        return invoiceRepository.findById(id)
                .orElseThrow(() -> new InvoiceNotFoundException(id));
    }
}

Advanced Cache Eviction and TTL Strategies

Once caching is working, you need eviction strategies to prevent stale data. Spring provides @CacheEvict to remove entries on update or delete. In a billing system, when an invoice is paid, you must evict the cached version so the next read fetches the updated status. Use @CacheEvict(key = "#invoice.id") on the update method. For bulk operations, use @CacheEvict(allEntries = true) but be careful — it clears the entire cache, causing a thundering herd problem where all subsequent requests hit the database simultaneously. Better to use partial eviction with keys. Also set appropriate TTL via RedisCacheConfiguration.entryTtl(). For invoices, 10 minutes is reasonable; for session data, 30 minutes; for reference data like tax rates, 1 hour. In production, we once set TTL too low (1 minute) for a frequently accessed cache, causing constant cache misses and defeating the purpose. Use Redis 'EXPIRE' command to verify TTL on cached keys. Another advanced technique is using @CachePut to update cache without evicting — it always executes the method and puts the result in cache, useful for write-through caching.

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

@Service
public class InvoiceServiceWithEviction {

    private final InvoiceRepository invoiceRepository;

    public InvoiceServiceWithEviction(InvoiceRepository invoiceRepository) {
        this.invoiceRepository = invoiceRepository;
    }

    @Cacheable(value = "invoices", key = "#id")
    public Invoice getInvoiceById(Long id) {
        return invoiceRepository.findById(id).orElseThrow();
    }

    @CachePut(value = "invoices", key = "#invoice.id")
    public Invoice updateInvoice(Invoice invoice) {
        return invoiceRepository.save(invoice);
    }

    @CacheEvict(value = "invoices", key = "#id")
    public void deleteInvoice(Long id) {
        invoiceRepository.deleteById(id);
    }
}

Monitoring and Alerting for Cache Health

In production, you need proactive monitoring. Integrate Spring Boot Actuator with Prometheus and Grafana. Expose cache metrics via micrometer: 'cache.gets' (with tags hit/miss), 'cache.puts', 'cache.evictions'. Create a Grafana dashboard showing cache hit ratio over time. Set alerts: if hit ratio drops below 80% for 5 minutes, page the on-call engineer. Additionally, use Redis's built-in 'MONITOR' command (careful — it's heavy) or 'RedisInsight' GUI to watch live commands. For the billing system, we set up a custom health indicator that queries Redis INFO stats and fails if keyspace_misses exceeds keyspace_hits by 2x. Also log cache misses at WARN level with the key — this helps correlate with specific requests. In the incident, the team had no monitoring on cache, so they didn't realize the miss ratio was 100% until the database started timing out. After implementing monitoring, they caught a similar issue in staging within minutes.

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;

@Component
public class CacheHealthIndicator implements HealthIndicator {

    private final RedisTemplate<String, Object> redisTemplate;

    public CacheHealthIndicator(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    @Override
    public Health health() {
        try {
            var connectionFactory = redisTemplate.getConnectionFactory();
            var connection = connectionFactory.getConnection();
            var info = connection.info("stats");
            long hits = Long.parseLong(info.get("keyspace_hits"));
            long misses = Long.parseLong(info.get("keyspace_misses"));
            double hitRatio = (double) hits / (hits + misses);
            if (hitRatio < 0.8) {
                return Health.down()
                        .withDetail("hitRatio", hitRatio)
                        .withDetail("message", "Cache hit ratio below 80%")
                        .build();
            }
            return Health.up().withDetail("hitRatio", hitRatio).build();
        } catch (Exception e) {
            return Health.down(e).build();
        }
    }
}

Preventing Future Incidents with Code Reviews and Testing

The ultimate fix is prevention. Add a custom Checkstyle or PMD rule that flags any service method calling a repository without a @Cacheable annotation (except write operations). Use ArchUnit tests to enforce that all read-only service methods in certain packages must have @Cacheable. In integration tests, use Redis test containers and verify cache behavior: call the method twice, assert that the second call returns faster (within Redis latency, not DB latency). Also test self-invocation scenarios by calling a cached method from within the same class and verifying the cache is bypassed — this should be a failing test. In code reviews, make it a checklist item: 'Is @Cacheable present on all read-heavy service methods?' Document the proxy limitation in your team's wiki. For the billing system, the team added a custom annotation @CachedRead that combines @Cacheable with a specific cache name and TTL, reducing boilerplate and enforcing consistency. They also added a PostConstruct method that logs all cache names at startup for verification.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.cache.CacheManager;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
class CacheAnnotationTest {

    @Autowired
    private CacheManager cacheManager;

    @Autowired
    private InvoiceService invoiceService;

    @Test
    void shouldHaveInvoiceCacheConfigured() {
        var cache = cacheManager.getCache("invoices");
        assertThat(cache).isNotNull();
    }

    @Test
    void shouldCacheResult() {
        var firstCall = invoiceService.getInvoiceById(1L);
        var secondCall = invoiceService.getInvoiceById(1L);
        // Both should return same instance if caching works
        assertThat(firstCall).isSameAs(secondCall);
    }
}