2025.12.21 // Architecture

Caching Systems (Part 2): Versioned Caches, Pub/Sub Invalidation, and Consistency

#cache #caching #system-design #invalidation #pubsub #versioning #consistency #redis

Part 1 explained caching layers and failure modes. This part is about keeping caches correct when data changes in a distributed system: versioned keys, event-driven invalidation, and the consistency trade-offs you actually live with.

1) Versioned caches: invalidate by changing the key

Instead of deleting keys, you bump a version and let old keys expire naturally.

Key pattern:

user:{id}:v{version}

How it works:

  • Store the current version in DB or a small metadata store.
  • Reads fetch the version, then read the versioned cache key.
  • Writes increment the version.

Pros

  • Invalidation is cheap and reliable (no delete storms).
  • Old keys can expire with TTL in the background.
  • Works across many caches and services.

Cons

  • Extra read (to get version) or version is cached too.
  • Requires a version store with strong write semantics.

Where it shines

  • User profiles, product pages, or any entity with frequent updates.
  • Multi-service systems where you cannot fan-out invalidations reliably.

2) Pub/Sub invalidation: push change events

In this model, writes publish an event. Consumers invalidate or update their caches.

Event payload (example):

{
  "entity": "user",
  "id": "123",
  "action": "updated",
  "ts": 1734790000
}

Typical flow

  1. Write to DB
  2. Publish event
  3. Cache owners receive event
  4. Invalidate or update cache

Why it fails if you do it naively

  • Events can be dropped, delayed, or reordered.
  • Consumers can be down when events publish.

How to make it reliable

  • Use an outbox pattern (store events in DB, publish asynchronously).
  • Make handlers idempotent.
  • Use a durable stream (Kafka/NATS) instead of volatile pubsub when correctness matters.

3) TTL is not enough; use soft TTL and stale-while-revalidate

TTL alone creates stampedes and synchronized expirations.

Better pattern

  • Soft TTL: consider cache stale before it truly expires.
  • Serve stale data briefly while one request refreshes in background.
  • Add jitter to TTL to avoid thundering herds.

Example strategy

  • Hard TTL: 10 minutes
  • Soft TTL: 8 minutes
  • If age > 8 minutes, refresh asynchronously

4) Stampede control: avoid N concurrent recomputations

When popular keys expire, you can melt the DB.

Mitigations

  • Singleflight (request coalescing)
  • Locking on recompute
  • Probabilistic early refresh
  • Pre-warming hot keys

5) Consistency is a choice, not a bug

There is no perfect cache consistency, only explicit trade-offs.

Common models

  • Eventual consistency: cheap, fast, some staleness
  • Bounded staleness: TTL-based, measurable drift
  • Read-your-writes: require versioning or session caches
  • Strong consistency: usually too expensive to maintain for caches

Rule of thumb

  • If a bug is catastrophic, skip caching for that path.
  • If staleness is acceptable, make it measurable and visible.

6) A practical decision matrix

Use this to pick a strategy per domain:

  • User profile: versioned keys + TTL + background refresh
  • Search results: TTL + soft TTL + async refresh
  • Feature flags: pub/sub with durable stream + short TTL
  • Financial balances: avoid cache or use read-your-writes session cache only

Final takeaway

Correctness in caches is not automatic. It requires:

  • deterministic invalidation (versioning),
  • durable change propagation (pub/sub + outbox),
  • and explicit consistency guarantees.

Part 3 shows how to build a cache-aside layer in Go with these patterns baked in.

← Back to Log