deployment and operations
Caching Basics
Production caching stores rebuildable copies closer to where they are needed. Use it to reduce repeated work while keeping source-of-truth ownership, expiry, invalidation, and fallback explicit.
Keep The Source Of Truth Clear
- Choose cache backend for local or shared needs.
- Use clear keys and TTLs.
- Delete affected keys after source changes.
Exercise Misses And Failure
- Measure before caching.
- Exercise miss and unavailable-cache paths.
- Monitor hit rate, latency, memory, and evictions.
Invalidate Deliberately
- Cache is not durable source of truth.
- Stale permissions and prices can be serious.
- Broad clears can overload dependencies.
Cache Read Path
read cache key
hit -> return cached value
miss -> load source of truth -> store with TTL -> return value
cache unavailable -> load source of truth -> log operational signal
Caching is ready when miss, staleness, and backend failure are safe. Prices, permissions, and authentication-related state deserve particular care because stale values can become correctness or security bugs.
Practice
Practice: Plan Production Cache Behaviour
Plan a cache for product summaries. Explain the miss path, invalidation path, and what the application does when the cache backend is unavailable.
Requirements
- Choose cache backend for local or shared needs.
- Use clear keys and TTLs.
- Delete affected keys after source changes.
- Measure before caching.
- Exercise miss and unavailable-cache paths.
- Monitor hit rate, latency, memory, and evictions.
Show solution
Keep the database as the source of truth. On a miss, load the product summary, store it with a deliberate TTL, and return it. Delete affected keys when product data changes.
In staging, test hit, miss, stale-value, and unavailable-cache behaviour. The app should fall back safely where possible and emit an operational signal. Monitor hit rate, latency, memory, and evictions after release.