The Cache That Doesn't Survive a Second Instance

Every demo on this topic worked with nothing but @EnableCaching and Spring Boot's own defaults — no Redis, no Caffeine, no configuration at all. That default is real, and it is also the one decision on this topic that genuinely does not survive contact with production.

With no other cache library on the classpath, Spring Boot falls back to a simple ConcurrentHashMap held in the memory of the running process. On one instance, that's a real cache, doing exactly what every card on this topic showed. Behind a load balancer with two or more instances, each one holds its own, completely separate map — an update on instance A leaves instance B's cache stale, silently, with nothing anywhere reporting a conflict.

The fix is a shared or coordinated cache provider — Redis for a cache every instance reads from the same place, or Caffeine paired with an invalidation mechanism when a local, in-process cache is still wanted. spring-boot-starter-cache doesn't pick one for you; it only wires up whatever provider it finds, or the fallback if it finds none.