Spring Cache.

Hook: Spring Cache is the sticky note on expensive work: if the answer for the same input has not changed, why pay for it twice?

Question: What is Spring Cache in Spring Boot, and how do you use it in production?

Answer: Spring Cache is a simple abstraction that lets you store method results and reuse them later instead of recomputing them. You turn it on with @EnableCaching and then use annotations like @Cacheable, @CachePut, and @CacheEvict on Spring beans. In production, the big ideas are: choose the right cache provider, define stable keys, and evict or update cached data when the source of truth changes.

Interview-Ready Answer: I use Spring Cache when a method is expensive but returns the same result for the same input. With @EnableCaching, Spring creates a proxy around the bean; on a cache hit it returns the stored value, and on a miss it runs the method and stores the result. I usually pair @Cacheable with explicit keys and a real provider like Caffeine or Redis, then use @CacheEvict or @CachePut to keep the data fresh.

What it is

Spring Cache is an abstraction (a common layer over different cache tools) for saving method outputs. The important mental model is simple: the method becomes the source of truth for building the value, but the cache becomes the fast path for repeated reads.

How it works under the hood

1. You annotate a Spring bean method and enable caching with @EnableCaching.
2. Spring wraps that bean in a proxy (a wrapper object that intercepts method calls). This is why caching works for calls that go through Spring, not for private helper calls inside the same class.
3. When a call arrives, Spring builds a cache key. If you do nothing, the default key generator uses the method arguments; for production, an explicit key is safer because it makes the rule obvious.
4. If you use condition, Spring checks it before the method runs. This is useful when you want to skip caching for certain requests.
5. For @Cacheable, Spring checks the cache first. On a hit, it returns the cached value immediately. On a miss, it runs the method, then stores the returned value.
6. If you use unless, Spring evaluates it after the method returns. This is how you can say, “do not cache nulls” or “do not cache very large results.”
7. @CachePut always executes the method and then updates the cache, while @CacheEvict removes one key or all entries. With beforeInvocation = true, eviction happens even if the method later fails.

When to use it

• Use it for read-heavy, expensive work: product details, reference data, configuration, permissions, or remote API responses.
• Do not use it when the data changes on every request, when freshness is critical to the millisecond, or when the result depends on hidden context you forgot to include in the key.
• For production, choose the provider by scope: in-memory for one JVM, Caffeine for very fast local caching, and Redis when multiple app instances must share the same cache.

Annotations compared

Performance and gotchas

• Average cache lookup is usually O(1); the miss path is the cache lookup plus the method cost. Space usage is O(n) for the number of entries.
• In-memory cache lookups are usually microseconds. A Redis round trip is often around 1-5 ms in the same region, which is still much cheaper than a database or remote API call, but it is not free.
• Default Boot behavior depends on classpath, but if you use the simple in-memory option, there is usually no TTL (time to live, meaning automatic expiration) and no distributed sharing across nodes.
• Self-invocation is the classic trap: if one method in the same class calls another cached method directly, the call bypasses the proxy and the cache is skipped.
• sync=true can reduce a thundering herd (many requests missing the cache at once) on one JVM, but it is not a distributed lock across all app instances.

One more production rule: cache keys must include everything that changes the output. If the same method returns different results by user, locale, tenant, or currency, those values belong in the key or the method should not be cached.

Real-World Example: Imagine a checkout service in an e-commerce platform. Product detail pages are hit thousands of times per minute, but the database row for a product changes only a few times a day. Spring Cache can store the product lookup result so the API returns in milliseconds instead of re-reading the database on every request.

Now the outage story: a developer updates the price in the database but forgets to evict or refresh the cache. The service keeps serving the old price for 15 minutes, and customers see a mismatch between the cart and checkout total. Symptoms include high cache hit rates, logs showing the update method ran, but the read endpoint never hitting the repository. Support gets complaints like “the page says one price and checkout says another,” and the root cause is stale cached data.

That is why production caching is not just about speed; it is about controlled freshness.

Follow-up & Tricky Questions:

• How is @Cacheable different from @CachePut? @Cacheable tries the cache first and skips the method on a hit, while @CachePut always runs the method and then writes the result. Use @CachePut when a write operation must refresh the cache immediately.
• How do you remove stale values after an update? Use @CacheEvict on the write path, or use @CachePut when the method already has the fresh value and you want to store it right away. For bulk changes, allEntries = true clears the whole cache.
• What is the difference between condition and unless? condition runs before the method and decides whether caching should happen at all. unless runs after the method and can veto storing the returned value.
• How do you create a custom cache key? Use the key attribute with a stable expression, usually SpEL (Spring Expression Language, a small expression language for Spring metadata). In production I prefer explicit keys so the rule is obvious to the next engineer.
• Which cache provider should I use? Use Caffeine for very fast local cache with size and time limits, and Redis when multiple app instances must share the same cache or you need TTL across the cluster. The choice is about freshness, sharing, and operational cost, not just speed.
• Does Spring Cache cache exceptions? No, the normal behavior is that only successful returns are stored. If the method throws, nothing is written, so the next request will try again.
• Does self-invocation use the cache? No. A direct call from one method to another inside the same class bypasses the proxy, so the cache advice never runs. That is one of the most common interview traps.
• Can I cache null values? It depends on the provider and your policy, so it is safer to decide explicitly with unless. Many teams avoid caching null for data that might appear soon after.

Tricky / Gotcha Questions:

• If the database row changes, does Spring automatically know? No. Spring Cache does not watch your database; you must evict or update the cache yourself when the source of truth changes.
• Is @Cacheable enough for write operations? Usually not. A write path often needs @CachePut or @CacheEvict because caching a read result does not magically keep it fresh after updates.
• Does the simple in-memory cache work in a multi-node deployment? It works inside one JVM only, so each node gets its own private copy. That can be fine for a demo, but it is dangerous for shared production data because nodes can disagree.

Common Mistakes:

• Using the default key blindly. Correction: choose an explicit key when the method output depends on more than one argument or on hidden context like tenant or locale.
• Forgetting eviction after writes. Correction: pair cached reads with @CachePut or @CacheEvict so updates do not leave stale values behind.
• Expecting self-calls to be cached. Correction: call the cached method through another Spring bean or move the logic so the proxy can intercept it.
• Using in-memory cache for everything. Correction: use it only when one JVM is enough; use Redis or another shared store when multiple instances must agree.

Memory Hook: Think of Spring Cache like a restaurant ticket board. If the same order comes back, the kitchen points to the ticket and serves the plate immediately; if the recipe changes, the old ticket must be torn down or you will serve the wrong meal.

Cheat Sheet:

• @EnableCaching turns the feature on.
• @Cacheable reads first, then computes on a miss.
• @CachePut always computes and refreshes the cache.
• @CacheEvict removes stale data.
• Proxy-based caching means self-invocation does not work.
• In production, choose the provider by scope: local speed, shared cluster, or TTL needs.

Practice Tasks:

1. Add a second argument to the product lookup, then change the cache key so both inputs affect the result.
2. Replace the in-memory cache manager with Caffeine and add a small expiry time so you can see values expire.
3. Create a method that calls a cached method internally, then move it to a separate bean and watch the cache start working again.