Caching
Published on
A cache trades freshness and operational complexity for lower latency and reduced backend load. Define the source of truth and acceptable staleness before selecting a cache product.
Placement and policy
Caches can live in a browser, CDN, gateway, application process, shared service, or database layer. Each placement changes ownership, key design, invalidation, privacy, and failure behavior.
- Cache-aside: application reads the cache, loads misses from the source, and populates results.
- Read-through: cache abstraction loads the source on a miss.
- Write-through: update cache and backing store in the write path.
- Write-behind: acknowledge before asynchronously persisting, increasing loss and ordering risk.
TTL limits staleness but does not guarantee freshness. Event-driven invalidation can be faster but depends on reliable delivery and version ordering. Include tenant, authorization context, representation, and schema version in keys where they affect the response.
Failure and capacity
Protect the source from stampedes with request coalescing, jittered expiry, prefetch, or stale-while-revalidate. Bound memory and understand eviction behavior. A cache outage should not automatically turn into an uncontrolled surge against the database.
Track hit ratio by workload, miss latency, evictions, memory, hot keys, stale responses, invalidation delay, and backend load. A high global hit ratio can hide a critical path that never hits.