การแคชแบบกระจายด้วย Redis และ TTL

Caffeine is a brilliant in-process cache: ultra-fast, but each application instance keeps its own private copy. The moment you scale horizontally to several pods, those copies drift apart.

• Instance A evicts a user; instance B still serves the stale entry.
• A cache warm-up on one node helps nobody else.
• Total memory cost grows linearly with replica count.

A distributed cache solves this by putting cache state in a shared backend that every instance reads and writes. In Spring Boot, Redis is the most common choice for this role.

Spring Boot's caching abstraction is backend-agnostic. To swap Caffeine for Redis you mostly change dependencies and a property — your @Cacheable annotations stay the same.

Pull in the Redis starter and the cache abstraction:

• spring-boot-starter-data-redis provides the connection and RedisCacheManager.
• spring-boot-starter-cache enables the @Cacheable/@CacheEvict annotations.

Then declare Redis as the cache type so Boot auto-configures a RedisCacheManager instead of a simple map.

Point Boot at your Redis server and tell the cache abstraction to use Redis. With spring.cache.type=redis, Boot wires a RedisCacheManager automatically.

• spring.data.redis.host / port configure the Lettuce client (the default driver).
• spring.cache.redis.time-to-live sets a default TTL for every entry.
• spring.cache.cache-names can pre-declare caches at startup.

This is the payoff of Spring's abstraction: the service code is identical to the Caffeine version. Only the CacheManager behind it changed.

Now when instance A populates products::42, instance B reads the very same key from Redis on its next call — no duplicate computation, no drift.

A TTL (time-to-live) is the maximum age of a cache entry before Redis evicts it automatically. TTLs are the primary defense against serving stale data in a distributed cache.

• Short TTL (seconds) → fresher data, more backend load.
• Long TTL (hours) → cheaper, but staleness risk grows.
• TTL is enforced server-side by Redis, so it applies uniformly to every instance.

Unlike Caffeine's expireAfterWrite, Redis TTLs survive a single instance restart because the data lives outside the JVM.

A single global TTL rarely fits every cache. Override the auto-configuration to give each cache its own expiry by supplying a RedisCacheManagerBuilderCustomizer (or a full RedisCacheManager bean).

Here products tolerates 30 minutes of staleness while volatile prices expires after 1 minute.

Redis stores bytes, not Java objects. Every cached value must be serialized on write and deserialized on read. The default RedisCacheManager uses Java's native serialization (JdkSerializationRedisSerializer), which has real drawbacks:

• Values are opaque binary blobs — unreadable with redis-cli.
• The cached class must implement Serializable.
• Tight coupling to class internals breaks across versions.

For interoperable, human-readable entries, switch the value serializer to JSON.

Use GenericJackson2JsonRedisSerializer for values and a plain StringRedisSerializer for keys. JSON keeps entries inspectable and decouples them from Java class internals.

The serializer embeds type metadata (@class) so polymorphic values deserialize back to the correct concrete type.

When several caches share one Redis database, their keys must not collide. By default Spring prefixes every entry with the cache name, so products::42 and users::42 stay separate.

• use-key-prefix: true (default) keeps caches isolated.
• You can supply a custom prefix, e.g. an app or tenant name, to share a Redis instance safely across services.

This matters most in multi-tenant or shared-infrastructure setups where one Redis serves many apps.

A distributed cache concentrates risk: when a hot key's TTL expires, every instance misses at once and stampedes the database — the thundering herd problem.

Mitigations:

• Stagger TTLs by adding a small random jitter so keys don't expire together.
• Refresh entries proactively before expiry rather than lazily on miss.
• Use a short-lived lock so only one instance recomputes a missed key while others wait.

This pure-Java helper shows how to compute a jittered TTL you would feed into entryTtl(...).

You don't have to choose. A common production pattern is a two-tier (near) cache:

• L1 — Caffeine in each instance, very short TTL, absorbs hot reads at nanosecond speed.
• L2 — Redis, shared across the cluster, the source of truth for cached state.

A request checks Caffeine first; on a miss it falls back to Redis; on a Redis miss it hits the database. This cuts network round-trips while keeping the cluster consistent. Spring can compose this with a CompositeCacheManager or a dedicated near-cache library.

Test your understanding of distributed cache trade-offs.

You moved from a private in-process cache to a shared, distributed one:

• Why Redis: one cache state across all instances eliminates drift and duplicated work.
• Drop-in swap: set spring.cache.type=redis and your @Cacheable code is unchanged.
• TTLs: Redis enforces expiry server-side, uniformly across the cluster, surviving instance restarts; tune per cache with a RedisCacheManagerBuilderCustomizer.
• Serialization: prefer GenericJackson2JsonRedisSerializer for readable, version-tolerant values over default JDK serialization.
• Key prefixes isolate caches sharing one Redis; TTL jitter and two-tier Caffeine+Redis caches tame the thundering herd.