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.