Built‑in In‑Memory Cache vs. Spring Cache for Thymeleaf Fragment Caching: Which Is Better for Stale Data Prevention?

Direct answer

Spring Cache backed by a distributed store such as Redis or Hazelcast is the better choice for preventing stale Thymeleaf fragments in a multi-node application. Thymeleaf's built-in cache is per-JVM, single-threaded, has no TTL, and requires manual clearing, so it cannot invalidate entries across nodes.

Likely explanation versus confirmed facts

Likely explanation

When backing data changes on one node, other nodes may continue rendering the cached fragment from their own memory. Because the built-in cache has no cross-node invalidation, the stale fragment remains until that node is manually cleared or restarted.

Confirmed facts

• Thymeleaf's built-in cache is per TemplateEngine and per JVM; entries are not shared across nodes.
• It provides no TTL or automatic eviction; clearing is manual.
• Spring Cache is an abstraction. With ConcurrentMapCache it is still local, but with Redis or Hazelcast it becomes distributed and supports TTL and cross-node eviction.
• Distributed lookups add network and serialization latency, usually small compared with fragment rendering and database access.

Answers to your scenarios

1. Built-in cache staleness: Any multi-node deployment where backing data changes without a template restart will serve stale fragments on nodes that did not restart. A restart fixes only the restarted node.
2. Eviction and latency: TTL bounds staleness but adds a small per-request cost on cache misses. LRU controls memory use but does not guarantee freshness. Both are slower than a static in-process map on a miss, but typically faster than regenerating the fragment from scratch.
3. Hybrid pattern: Not recommended as the primary staleness fix. The built-in half still cannot be invalidated remotely, so it only works for fragments that are safe to serve stale until restart.

Steps for this case

1. Enable Spring Cache and configure Redis or Hazelcast as the cache manager; do not rely on the default local map in a cluster.
2. Cache fragment output under a key that includes the fragment identifier and a data version or tenant identifier.
3. Set a TTL, for example 60 seconds, so entries expire automatically if invalidation is missed.
4. Evict the same key whenever the underlying data changes, on the node that handles the write.
5. Verify on two nodes behind a load balancer: update data, expire or evict the key, then request the fragment on both nodes and confirm the rendered output changes.

Missing diagnostic detail

Do you already operate Redis or Hazelcast in this cluster? If not, the recommendation shifts from adding Spring Cache with Redis to using Spring Cache with short local TTL plus application-level invalidation events, because introducing a distributed cache only for fragments may be disproportionate.

Assumptions and uncertainty

This assumes Thymeleaf 3.x with Spring Boot 3.x / Spring Framework 6.x and multiple JVM nodes behind a load balancer. No latency measurements are included; treat any specific millisecond figure as unverified until you benchmark your cache provider and fragment size.

Verification

spring.cache.type=redis
spring.cache.redis.time-to-live=60s

Confirm with a two-node test: request a fragment, update its data, wait for TTL or send an eviction, then request again on both nodes. Updated output on both nodes indicates cross-node freshness is working.