Caching stores frequently accessed, expensive-to-compute data in memory, and it must be explicitly invalidated or refreshed whenever the underlying source data changes to avoid serving stale results.
Key Points: • Spring's caching abstraction (@Cacheable, @CachePut, @CacheEvict) lets you declare caching behavior without hand-writing cache lookups. • @Cacheable stores the method's result keyed by its arguments and skips re-execution on a cache hit. • @CacheEvict removes the entry so the next call recomputes and repopulates it -- used right after an update or delete. • @CachePut always executes the method and updates the cache with the fresh result, useful for write operations that should also update the cache immediately. • A backing store like Redis or Caffeine is chosen based on whether the cache needs to be shared across instances (Redis) or just local and fast (Caffeine).
Example: Product prices are cached with @Cacheable to avoid hitting the database on every page view; when an admin updates a price, the update method is annotated with @CacheEvict on that product's cache key so the next read fetches the fresh price instead of a stale one.
Code Example:
@Cacheable(value = "products", key = "#id")
public Product getProduct(Long id) { ... }
@CacheEvict(value = "products", key = "#product.id")
public void updateProduct(Product product) { ... }Interview Tip: A concise interview answer is:
"I use @Cacheable for read-heavy, rarely-changing data like product details, and pair it with @CacheEvict on the update path so the cache is cleared the moment the underlying data changes. That keeps performance high without serving stale data to users."