Redis & Caching Strategies

Match the structure to the access pattern: sorted set for the leaderboard, hash for sessions, HyperLogLog (or set) for unique counts, and a list or stream for queues.

• Sorted set: ZADD board 1500 user:7, ZREVRANGE board 0 9 WITHSCORES, O(log N) updates and rank queries.
• Hash: HSET session:abc uid 7 role admin lets you update single fields and EXPIRE the whole key.
• HyperLogLog: PFADD uv:2026-10-04 user:7, about 12 KB per key with ~0.8% error; a set is exact but memory grows linearly.
• Streams with consumer groups give acknowledgements and replay; lists (LPUSH/BRPOP) lose a message if the consumer crashes after popping.

In cache-aside the application reads the cache first; on a miss it loads from the database, writes the value into the cache with a TTL and returns it. Writes go to the database and then evict (or update) the cache entry.

@Cacheable(cacheNames = "product", key = "#id")
public ProductDto get(long id) { return repo.findById(id).map(ProductDto::from).orElseThrow(); }

@CacheEvict(cacheNames = "product", key = "#id")
public void update(long id, UpdateReq r) { /* update DB */ }

• Only requested data is cached, and a cache outage degrades to DB reads rather than failure.
• The first request after eviction is always slow, and there is a stale window between DB write and eviction.

Write-through writes cache and DB synchronously through a cache layer, write-behind writes the cache and flushes to the DB asynchronously, and cache-aside leaves both to the application.

• Write-through: strong read-your-writes, higher write latency, caches data that may never be read.
• Write-behind: lowest write latency and batching, but data loss if the cache node dies before the flush, and the DB lags behind. Fits counters, analytics, view counts.
• Redis itself has no built-in write-through to your RDBMS; you need a library, Redis Gears/RedisGears-style tooling, or application code.
• Cache-aside is the default for most Spring services because it is simple and tolerant of cache failure.

Keys with a TTL are expired lazily on access and by a periodic sampling job; when maxmemory is reached, the maxmemory-policy decides what to evict (or whether to reject writes).

• allkeys-lru / allkeys-lfu: pure cache; evict from all keys. LFU suits skewed popularity.
• volatile-lru / volatile-ttl: evict only keys with a TTL; if none exist, writes fail with OOM error.
• noeviction (default): writes error out when full; right when Redis is a datastore (queues, locks).
• LRU/LFU are approximate (sampled via maxmemory-samples, default 5).
• Add random jitter to TTLs to avoid synchronized expiry.

RDB is a periodic point-in-time snapshot (fast restart, compact, can lose minutes of writes); AOF logs every write and replays on restart (loss bounded by fsync policy).

• appendfsync always loses nothing but is slow, everysec (default) loses up to about 1 second, no leaves it to the OS.
• Since Redis 7, AOF is multi-part (base RDB + incremental files); background rewrite compacts it.
• Common production setup: AOF everysec plus RDB snapshots for backups. For a pure cache, persistence can be disabled.
• fork() for snapshots/rewrites can cause latency spikes and memory growth with copy-on-write on large datasets.

Replication copies data to read replicas asynchronously; Sentinel adds monitoring and automatic failover for one master; Cluster shards data over 16384 hash slots across multiple masters and has built-in failover.

• Replication is asynchronous, so a failover can lose recently acknowledged writes; WAIT reduces but does not eliminate that.
• Sentinel: needs a quorum (3+ sentinels); clients ask Sentinel for the current master.
• Cluster: slot = CRC16(key) mod 16384; multi-key commands and Lua scripts require all keys in the same slot, forced with hash tags like {user:7}:cart.
• Replica reads can be stale; Lettuce supports ReadFrom.REPLICA_PREFERRED.

Use SET lock:key <unique-token> NX PX 30000 to acquire, and release with a Lua script that deletes only if the value still equals your token. Locks give only best-effort mutual exclusion because of pauses and clock issues.

Boolean ok = redis.opsForValue().setIfAbsent("lock:order:42", token, Duration.ofSeconds(30));
// release
String lua = "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
redis.execute(new DefaultRedisScript<>(lua, Long.class), List.of("lock:order:42"), token);

• A GC pause or network delay longer than the TTL lets a second client acquire the lock while the first still believes it holds it.
• Async replication: a failover can hand the lock to a new master that never saw it. Redlock (majority of 5 independent masters) tries to fix this but depends on bounded clock drift and pauses; critics (Kleppmann) argue it is unsafe for correctness.
• For correctness, use a fencing token checked by the resource (DB version column) or a DB/ZooKeeper-style lock; use Redis locks for efficiency (avoid duplicate work).
• Redisson provides watchdog lease renewal.

Fixed window uses INCR plus EXPIRE per window key; sliding window log uses a sorted set of timestamps; token bucket stores tokens and last-refill time updated atomically in Lua.

String lua = "local c=redis.call('INCR',KEYS[1]) if c==1 then redis.call('PEXPIRE',KEYS[1],ARGV[1]) end return c";
Long count = redis.execute(new DefaultRedisScript<>(lua, Long.class), List.of("rl:user7:" + minute), "60000");
boolean allowed = count != null && count <= 100;

• Fixed window is cheap but permits a 2x burst across a window boundary.
• Sliding log is accurate but O(requests) memory; sliding counter approximates with two windows.
• Token bucket allows controlled bursts. Always make read-modify-write atomic (Lua or MULTI with WATCH).
• Decide fail-open vs fail-closed when Redis is down.

A hot key lives on one shard, so adding nodes does not help. Reduce load on that key with a local in-process cache, replicate the key under several names, or split it.

• Detect with redis-cli --hotkeys (needs LFU policy), MONITOR on a sample (costly), or client-side metrics.
• Local cache (Caffeine) with a short TTL in front of Redis cuts network calls per instance.
• Key splitting: write product:1:{0..9}, read a random replica copy; accept staleness while updating all copies.
• Read from replicas for read-heavy keys.

A big key is a single key holding a huge value (a multi-million element hash/list/set or multi-MB string). Because Redis executes commands on one thread, operating on or deleting it blocks all other clients, and it unbalances cluster shards and replication.

• Find with redis-cli --bigkeys or MEMORY USAGE key; scan with SCAN, never KEYS *.
• Delete with UNLINK (asynchronous free) instead of DEL; iterate with HSCAN/SSCAN/ZSCAN instead of HGETALL/SMEMBERS.
• Split into buckets (user:7:cart:{hash%16}) or paginate; compress large JSON values.
• Set lazyfree-lazy-user-del yes so even DEL is lazy.

This is a cache stampede (dogpile): many concurrent misses on the same expired key all recompute the value. Prevent it by allowing only one loader per key, or by refreshing before expiry.

• In-process single flight: @Cacheable(sync = true) serializes loaders per key within one JVM only.
• Cross-instance: short Redis lock (SET NX PX) so one node reloads while others wait briefly or serve stale data.
• Probabilistic early refresh (XFetch) or a soft TTL stored inside the value: serve stale and refresh asynchronously.
• Jittered TTLs and pre-warming hot keys.

Penetration is repeated requests for keys that exist nowhere (always miss, always hit DB); breakdown is one hot key expiring; avalanche is many keys expiring together or the cache dying, flooding the DB.

• Penetration: cache negative results with a short TTL (for example 30-60 s), validate input, or use a Bloom filter of valid IDs.
• Breakdown: mutex/single flight or logical expiry (see stampede).
• Avalanche: randomize TTLs, multi-layer caches, rate limit and circuit-break DB access, keep Redis highly available, degrade gracefully.
• Bulkhead the DB with a small connection pool so a cache outage queues rather than kills it.

RedisTemplate defaults to JDK serialization (JdkSerializationRedisSerializer): unreadable, large, and tied to class structure (serialVersionUID). Prefer JSON (GenericJackson2JsonRedisSerializer or typed Jackson2JsonRedisSerializer) or a schema-based format.

RedisCacheConfiguration cfg = RedisCacheConfiguration.defaultCacheConfig()
    .entryTtl(Duration.ofMinutes(10))
    .serializeKeysWith(SerializationPair.fromSerializer(new StringRedisSerializer()))
    .serializeValuesWith(SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

• Rolling deploys: old and new versions share the cache, so adding or removing fields can cause deserialization errors; use tolerant mapping (FAIL_ON_UNKNOWN_PROPERTIES=false) or include a version in the cache name or key.
• GenericJackson2JsonRedisSerializer embeds @class type info, which couples the cache to class names and is a deserialization security surface.
• Protobuf is compact and evolvable, but less debuggable.

Lettuce (the Spring Boot default) is Netty-based and thread-safe, so one connection is shared across threads; Jedis is not thread-safe and needs a connection pool.

spring:
  data:
    redis:
      host: redis
      timeout: 500ms
      lettuce:
        pool:
          enabled: true
          max-active: 16

• Set command timeouts; default is 60 s in Lettuce, which hangs request threads during an outage.
• A shared connection is not suitable for blocking commands (BLRPOP) or transactions, so those need dedicated or pooled connections (pooling needs commons-pool2 on the classpath).
• For Cluster, enable topology refresh (adaptive refresh) or clients keep talking to stale nodes after failover.
• Boot 3 uses spring.data.redis.* (Boot 2 used spring.redis.*).

With allkeys-lru, memory pressure can evict session and lock keys, logging users out or silently releasing locks. Cache data and durable data have different failure contracts, so separate them.

• Use separate instances (or clusters) per role: eviction-enabled cache vs noeviction for sessions, queues, locks.
• Alternatively use volatile-* policy and ensure only cache keys carry TTLs, but this is fragile.
• Monitor evicted_keys, used_memory, hit ratio (keyspace_hits / (hits + misses)) and latency metrics; alert on eviction of non-cache keys.
• Namespace keys (app:cache:*, app:lock:*) so you can audit what is stored.