System Design Cases
Cache Coherence
Cache Coherence concept page: multi-level invalidation across browser/CDN/app cache/DB, write strategies trade-offs (write-through vs write-back vs write-around), invalidation race conditions, cache stampede protection via single-flight, multi-DC propagation via CDC + Kafka. Five scenarios covering write-through happy path, write-back data loss risk, invalidation race, stampede + single-flight fix, and multi-DC eventual coherence window.
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
- Build a key that includes tenant, authorization-relevant scope, representation, and schema version.
- Read the cache.
- On miss, obtain a per-key fill lease/token or singleflight slot.
- Read authoritative state and its version.
- Fill with compare-and-set only if no newer generation/invalidation has appeared.
- 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.