Spring Boot's default caching mechanism, the simple in-memory ConcurrentMap-based cache, has real limitations that make it unsuitable for anything beyond small, single-instance applications.
Key Points: • Cached data lives only in the local JVM heap, so it doesn't scale across multiple application instances. • Different instances behind a load balancer can serve inconsistent cached data since caches aren't shared. • All cached entries are lost whenever the application restarts, with no persistence. • There's no built-in eviction policy tuning, expiration, or size limiting out of the box. • Distributed alternatives like Redis or Hazelcast solve these gaps by providing shared, persistent, and configurable caching.
Example: A three-instance deployment using the default cache can show one user stale product pricing while another instance shows updated pricing, simply because each JVM maintains its own independent cache copy.
Interview Tip: A concise interview answer is:
"Spring Boot's default cache is just an in-memory ConcurrentMap, so it doesn't scale across multiple instances, causes inconsistent data in a distributed deployment, and loses everything on restart with no eviction tuning. For anything beyond a single-instance app, I'd switch to Redis or Hazelcast for a shared, durable cache."