Cache Invalidation Scenarios

The cache and the database are two stores updated by separate operations that cannot be made atomic, so any ordering leaves a window where readers see old data or, worse, old data is stored permanently.

• Thread A reads a miss and loads value v1 from the DB. Thread B updates the DB to v2 and evicts the key. Thread A then writes v1 into the cache. v1 stays until the TTL expires.
• Every invalidation strategy only narrows the window; the TTL is the safety net that bounds how long staleness can last.

Update the DB first, then delete the cache entry. Deleting first lets a concurrent reader refill the cache with the old value before the DB commit, leaving stale data indefinitely.

• Delete-then-update race: B deletes key; A misses and reads old DB row; B commits; A writes old value to cache.
• Update-then-delete race is far rarer: it needs a read that started before the commit to write to the cache after the delete (a reader slower than a writer including its commit).
• If the delete fails (network), the entry stays stale: retry via a queue, or rely on TTL.
• Delayed double delete (delete again after ~500 ms) is a heuristic, not a guarantee.

@CacheEvict runs on method return, which is before the transaction commits. A reader between eviction and commit misses, reads the old committed row, and re-caches it.

@Transactional
public void update(long id, Req r) {
    repo.save(apply(id, r));
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
        @Override public void afterCommit() { cache.evict(id); }
    });
}

• Alternative: publish an event and handle it with @TransactionalEventListener(phase = AFTER_COMMIT) that evicts.
• Spring's RedisCacheManager can be wrapped with .transactionAware() so put/evict are deferred until commit.

A CDC tool reads the database transaction log (binlog/WAL) and emits one event per committed change; a consumer evicts or refreshes the matching cache keys. Because it is driven by the commit log, it catches every writer (other services, SQL scripts, admin fixes) and never fires for rolled-back transactions.

• Delivery is at-least-once, so eviction must be idempotent; deleting a key twice is harmless.
• Ordering per primary key is preserved within a Kafka partition, so key by primary key.
• Cost: extra infrastructure and a lag of typically tens to hundreds of milliseconds, so there is still a small stale window.
• Combine with a TTL as a safety net, and pair with the write path doing a local eviction for read-your-writes.

Include a version in the key (product:42:v17, or a namespace counter ns:product:7 embedded into keys) so a change creates a new key instead of mutating an old one. Stale entries become unreachable and age out by TTL.

• Using the row's version/updated_at read from the DB makes each cache value immutable, so a late writer can only write the old version's key, never overwrite the new one.
• Bulk invalidation: bump a namespace version (INCR ns:catalog:ver) and all keys of that namespace are orphaned in O(1) without KEYS/SCAN.
• Cost: you need the current version first (one cheap lookup) and orphaned entries consume memory until TTL or eviction.
• Useful for CDN/static assets (app.3f9a.js) and cache-busting after deploys that change serialization.

Stale data can sit in the browser, CDN, API gateway, application local cache (Caffeine), Redis, Hibernate second-level or query cache, and replica lag in the database. Trace from the outside in using response headers, then bypass layers one by one.

• Check Cache-Control, Age, ETag and CDN hit headers (X-Cache).
• Hit the app instance directly, then compare local cache vs Redis (GET key, TTL key) vs the DB primary vs a replica.
• Local caches are per instance: invalidating Redis does not clear Caffeine on other nodes; broadcast evictions via Redis pub/sub or Kafka.
• Each layer's TTL adds up: worst-case staleness is roughly the sum along the path.

On write, evict L2 and publish an invalidation message; every instance subscribes and evicts its own L1 key. Keep L1 TTL short (seconds) because messages can be lost.

• Redis pub/sub is fire-and-forget: a disconnected instance misses messages, so short L1 TTLs cap the damage. Streams or Kafka give replay.
• Redis 6+ client-side caching (CLIENT TRACKING) has the server push invalidations for keys a client read; supported by Lettuce.
• Without invalidation, accept L1 staleness equal to its TTL; reserve L1 for data that tolerates that (config, reference data).
• Libraries: Spring CompositeCacheManager does not do this by itself; use a library or custom Cache wrapper.

Decide per data type by the cost of showing stale data. Cache-aside with TTL gives eventual consistency; strong consistency requires bypassing the cache (or reading through the primary) for the critical path.

• Tolerate minutes: product descriptions, counts, recommendations.
• Tolerate seconds: inventory display; but the checkout decrement must hit the DB with a constraint or atomic update.
• Tolerate nothing: balances, permissions revocation, prices at payment time; read from the source of truth.
• Read-your-writes: after a user's own update, serve their next read from the DB or the freshly written value (sticky route or a short per-user "recent write" marker).
• Never base a write decision on cached data without validating against the DB.

Service B's writes never invalidate the cache, so readers see stale data until TTL. Cache invalidation must be tied to the data change, not to one code path.

• Short term: both services share an eviction helper or publish a domain event (ProductChanged) via outbox that triggers eviction.
• Better: single owner service for the table, other services call its API.
• Most robust: CDC from the table's log (see CDC question) so even manual SQL updates invalidate.
• Document cache key naming so the same key is used everywhere.

Redis replication is asynchronous, so the promoted replica may be missing the latest writes (including evictions), and deleted keys can reappear. Stale or resurrected entries then persist until TTL.

• Lost evictions: after failover, a key you deleted may exist again with the old value; bounded TTLs limit the damage.
• Lost locks and counters: rate limits and locks can briefly reset or be double-held.
• After a failover where the new master is empty (restart without persistence), you get a cold cache and a DB surge (see warm-up).
• Mitigation: TTLs on everything, min-replicas-to-write, idempotent operations, flush or version-bump the namespace after a failover if correctness requires it.
• Lettuce must refresh topology to find the new master; set connection timeouts so threads do not hang.

A cold cache sends nearly all traffic to the database. Pre-load the hottest keys before taking traffic and ramp load gradually.

• Warm via a startup job or readiness gate: load top-N keys (from access logs or a "hot list" table) with bounded concurrency.
• Persist cache (RDB/AOF) so a restart is not cold; for a rolling deploy of the app, Redis is unaffected.
• Ramp: let the load balancer or Kubernetes shift traffic slowly; use request coalescing and rate limiting on the DB path.
• Stagger TTLs during preload (jitter) so the warmed keys do not all expire together.

Avoid scanning for patterns in production. Use a tag-to-keys index set, or version the namespace so all related keys die at once.

• Tag index: when caching list:cat:5:page:2, also SADD tag:cat:5 list:cat:5:page:2; on change, SMEMBERS then UNLINK them and the tag set. Race: concurrent fills can add keys after the sweep, so keep TTLs.
• Namespace version: key = list:cat:5:v{ver}:page:2; bump ver to invalidate everything in O(1).
• KEYS pattern is O(N) and blocks; SCAN with MATCH is non-blocking per call but still walks the entire keyspace and in Cluster must run per node.
• Cache fewer composite lists; cache entities by ID and assemble lists, so one entity change invalidates one key.

The L2 entity cache is updated or evicted when entities change through Hibernate; changes by native SQL, bulk HQL updates or other applications bypass it and leave stale data. The query cache is invalidated per table: any write to a table the query reads invalidates all cached results of those queries.

• Query cache stores only IDs; each row is then fetched from L2 or the DB, so enabling it without entity caching can add queries.
• Use @Cache(usage = READ_WRITE) for read-mostly entities; NONSTRICT_READ_WRITE accepts brief staleness; TRANSACTIONAL needs JTA support in the provider.
• Native updates need evictEntityRegion or @NamedNativeQuery with synchronized query spaces.
• In a cluster the provider must propagate invalidation (JCache with Hazelcast/Infinispan/Redisson); a local-only cache goes stale on other nodes.

Sample reads and compare the cached value to the source, and track hit ratio, eviction counts and invalidation lag as metrics.

• Shadow-read: for 0.1% of cache hits, also read the DB and log a metric cache.stale{type} when values differ (compare version or updated_at).
• Store cachedAt or version in the value so you can compute age at read time and histogram it.
• Track invalidation pipeline lag (CDC consumer lag) and failed evictions (dead-letter queue size).
• Alert on rising DB load with a falling hit ratio (a stampede or avalanche signature).

Two concurrent writers can commit to the DB in order 1, 2 but write to the cache in order 2, 1, leaving the older value cached. Make the cache write conditional on a monotonically increasing version.

String lua = "local cur=redis.call('HGET',KEYS[1],'v') " +
  "if (not cur) or tonumber(cur) < tonumber(ARGV[1]) then " +
  "redis.call('HSET',KEYS[1],'v',ARGV[1],'data',ARGV[2]) return 1 else return 0 end";
redis.execute(new DefaultRedisScript<>(lua, Long.class), List.of("product:42"), "17", json);

• The version comes from the DB (@Version column, sequence or LSN).
• A stale writer's script returns 0 and does nothing.
• Serializing writers through a per-key queue or lock is the alternative, at a throughput cost.