cache-design

What problem does it solve?

It prevents cache design from becoming an accidental source of truth or an outage amplifier by enforcing explicit ownership, freshness budgets, safe invalidation, and defenses against stampedes, penetration, and avalanche effects.

Core Features & Use Cases

• Bounded acceleration layer: Define cache correctness by staleness tolerance, not by hoping TTLs behave.
• Safe cache contracts: Specify per-value owner, source of truth, versioned key/value schemas, TTL with jitter, and bounded stale-serve behaviors.
• Operational safeguards: Add stampede protection (single-flight/leases/XFetch), penetration protection (negative caching + bloom/existence checks), and avalanche protection (warm-up, coalescing, origin rate limiting).
• Tenant and permission isolation: Ensure tenant + permission scoping lives in the cache key to avoid cross-tenant leaks.
• Observability and security: Require cache hit/miss/stale/eviction/source-load metrics and prevent secrets/PII leakage in logs, keys, and HTTP cacheability.

Quick Start

Ask an architect to produce a cache strategy that includes versioned key/value schemas with tenant+permission scoping, TTL with jitter, explicit invalidation triggers, and required observability for hit/miss/stale and failure modes.