	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Microservices > Spring Boot > Spring Boot Caching with @Cacheable

Spring Boot Caching with @Cacheable

Author: Venkata Sudhakar

Caching stores the result of an expensive method call so that subsequent calls with the same arguments return the cached result instantly without re-executing the method. In Spring Boot, @Cacheable is the annotation that enables this - add it to any service method and Spring intercepts the call, checks whether a cached result exists for the given arguments, and either returns the cached value or calls the method and stores the result for next time. This is ideal for data that is read frequently but changes rarely: product catalogues, configuration lookups, user permissions, and reference data.

Spring Cache is an abstraction layer - the actual storage backend is pluggable. For development and single-server deployments, the default ConcurrentMapCacheManager stores cached values in a Java ConcurrentHashMap in memory. For production multi-server deployments, configure Redis as the cache backend so all server instances share the same cache. The cache name in @Cacheable maps to a named cache region, and the key is derived from the method arguments by default.

The below example shows caching a slow database lookup with @Cacheable, evicting the cache when data changes with @CacheEvict, and updating the cache with @CachePut.

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

@Configuration
@EnableCaching  // Must be present to activate caching
public class CacheConfig {}

@Service
public class ProductService {

// @Cacheable: cache result by productId
    // First call: executes method, stores result in "products" cache with key=productId
    // Subsequent calls with same productId: return cached value, method NOT called
    @Cacheable(value = "products", key = "#productId")
    public Product findById(Long productId) {
        System.out.println("  [DB] Loading product " + productId + " from database...");
        // simulate slow DB call
        try { Thread.sleep(500); } catch (InterruptedException e) {}
        return new Product(productId, "Product " + productId, 49.99);
    }

// @CacheEvict: remove from cache when product is deleted
    @CacheEvict(value = "products", key = "#productId")
    public void delete(Long productId) {
        System.out.println("  [DB] Deleting product " + productId);
        // Next findById call for this ID will hit the database again
    }

// @CachePut: always executes method AND updates the cache with the result
    // Use for updates - keeps cache fresh without requiring a new read
    @CachePut(value = "products", key = "#product.id")
    public Product update(Product product) {
        System.out.println("  [DB] Updating product " + product.id());
        return product;
    }
}

It gives the following output,

// First call - hits database:
findById(101):
  [DB] Loading product 101 from database...
  -> Product{id=101, name="Product 101", price=49.99}  (took 500ms)

// Second call - returns from cache instantly:
findById(101):
  -> Product{id=101, name="Product 101", price=49.99}  (took 0ms, no DB call)

// After update - cache entry refreshed:
update(Product{id=101, name="Updated", price=59.99})
  [DB] Updating product 101
findById(101):
  -> Product{id=101, name="Updated", price=59.99}  (from cache, already updated)

// After evict - next call hits DB again:
delete(101)
  [DB] Deleting product 101
findById(101):
  [DB] Loading product 101 from database...  (cache was evicted)

application.properties for Redis caching with TTL,

spring.cache.type=redis
spring.data.redis.host=redis-server
spring.data.redis.port=6379
spring.cache.redis.time-to-live=600000
# TTL of 10 minutes - cached values expire automatically after 10 min
# All app instances share the same Redis cache

@Cacheable only works when the method is called from outside the class - calling a @Cacheable method from within the same class bypasses the proxy and goes directly to the database. Cache the result of the outermost service call your application makes. Also remember that the cached object must be serializable if you use Redis. A common mistake is caching JPA entities that have lazy-loaded collections - always cache DTOs or simple value objects, not JPA entities.

Send your comments, suggestions or queries regarding this site to [email protected].