Skip to content
AITroveRead. Build. Understand.
Make this comfortable

Spring Redis cache serialization: roll payload formats without mixed readers

Last updated: 5 Oct 20264 min read
tutorial
IntermediateBy AITrove Editorial

Version the cache namespace before a payload or serializer change so old values are never decoded under a new contract.

Cache entries have a wire format

A receipt view stored in Redis is bytes, not a Java object shared in memory. A serializer change, renamed field or new application version can make an existing entry unreadable. Treat the cache name and prefix as a format boundary: write the new view under receipt-view-v4 while old nodes continue using receipt-view-v3. Key schemas cover tenant and identifier separation; the version covers payload interpretation.

Roll forward in stages

Deploy code that can read its new namespace and refill it from the database. Keep the old namespace until old nodes leave traffic, then let its TTL retire entries. Do not mass-delete a shared Redis instance just to clear one application cache. Pin the serializer in configuration, test real encoded bytes from the previous release, and reject permissive polymorphic decoding of untrusted values. If two versions must share keys, use a deliberately backward-compatible envelope and a migration test instead of hope.

Measure the cold interval

A new namespace produces a temporary cache-miss wave. Stage rollout capacity, rate-limit expensive rebuilds and record miss ratio by bounded cache name. Test an old payload, a new payload, a corrupted value and an entry written by a node mid-rollout. A corrupt cache entry should not silently become a wrong receipt; classify and evict it or fail the request according to the data contract. Commit-safe invalidation remains necessary after writes.

Implementation contract

properties
spring.cache.cache-names=receipt-view-v4
spring.cache.redis.time-to-live=47m
spring.cache.redis.use-key-prefix=true
spring.cache.redis.key-prefix=receipt-api:

Cost and verification

A version change temporarily duplicates old and new entries and increases database reads while the new cache warms. TTL bounds the old storage footprint; coordinated deployment and targeted metrics bound the cold-cache load.

Common Mistakes

  • Do not change a serializer while leaving old and new nodes on the same undecorated cache keys.
  • Do not clear an entire shared Redis database to retire one payload format.
  • Do not permit broad untrusted type deserialization merely to read legacy entries.

Read next

Spring Redis cache key schema: tenant, prefix and rollout version, Spring Redis cache TTL versus idle expiry: GETEX changes the read contract, Spring cache after commit: keep rolled-back writes out of readers, Spring cache keys: separate tenants and test the loader count, Spring Boot metrics: bound tag values instead of tracking each receipt.

spring
spring-boot
production
redis-cache-serialization-rollout
Storage details