Caching coherence

Cache coherence is an end-to-end contract for freshness, ordering, invalidation, fill races, and failure. TTL alone is expiration policy, not proof that all readers see one current value.

Cache-aside read

1. Build a key that includes tenant, authorization-relevant scope, representation, and schema version.
2. Read the cache.
3. On miss, obtain a per-key fill lease/token or singleflight slot.
4. Read authoritative state and its version.
5. Fill with compare-and-set only if no newer generation/invalidation has appeared.
6. Wake waiters with a bounded timeout/fallback.

Without a fenced fill, this race is possible: reader misses, reads old database value; writer commits and invalidates; reader then fills the old value.

Write and invalidation

Commit the authoritative write first. Record an outbox event in the same transaction, then publish at least once. Invalidation consumers are idempotent and compare per-key versions, so a late duplicate cannot delete or restore newer state.

A delete uses a versioned tombstone long enough to reject a late stale fill. Cross-region ordering needs an explicit per-key version/epoch or conflict rule; broker arrival order alone is insufficient.

Stampede control

In-process singleflight collapses requests only within one process. A fleet needs a distributed lease or cache-supported request collapse. Bound lease duration and waiter time, and decide whether stale-while-revalidate is permitted for this data class. Never serve stale authorization or revocation state merely to improve availability.

HTTP cache rules

HTTP caching additionally depends on cache keys and Vary, freshness lifetime, Age, validators such as ETag, and directives including no-store and must-revalidate. Unsafe-method responses can invalidate stored responses. Shared caches must not reuse private/authenticated representations outside their contract.

Write-through and write-back

Write-through should not acknowledge before the authoritative durability contract is met. Write-back acknowledges earlier and can lose/reorder data unless the cache layer is itself a durable, replicated, ordered write authority with recovery semantics. Ordinary Redis used as a disposable cache does not acquire those guarantees by being called "write-back."

Diagram scenarios

The animation covers a policy-valid hit, fenced miss fill, transactional-outbox invalidation, stampede collapse, reordered events, and volatile write-back loss.

Related concepts

Interactive scenarios