AT4 — Precomputation vs. On-Demand
Caching is precomputation: you compute the result once and store it, paying the database query cost on the first miss, then serving all subsequent requests from cache. The benefit grows with the read-to-write ratio. For a user profile read 10,000 times per day but updated once, the cache pays off 9,999 times. For a user profile updated 10 times per day and read 11 times, the cache adds complexity without proportional benefit.
AT1 — Consistency vs. Availability
A cache hit avoids the database — it is fast and available. A cache hit on stale data is incorrect — it sacrifices consistency for availability. Every caching decision is this tradeoff. TTL is the explicit control knob: shorter TTL = more consistent, more database load; longer TTL = faster, more stale.
Four strategies, each occupying a different position on the consistency-complexity axis:
| Strategy | When to Use | Consistency Guarantee | Operational Complexity |
|---|---|---|---|
| TTL-based | Staleness up to TTL duration is tolerable; writes are frequent or write paths are many | Stale reads for up to TTL seconds | Low — set TTL at write time; no additional plumbing |
| Event-driven invalidation | Near-zero staleness required; a reliable event pipeline exists; write paths are few and known | Near-zero staleness (bounded by event pipeline latency) | Medium — requires event publisher, subscriber, and dead-letter handling |
| Cache-aside (lazy loading) | Read-heavy workload; cold start is acceptable; write patterns are unpredictable | Stale until next read after TTL expiry or explicit delete | Low-medium — application manages cache fill on miss |
| Write-through | Write volume is low; all write paths are controlled; stale reads are unacceptable | No staleness for the written key (assumes cache write succeeds) | Medium-high — every write path must update cache; failure between DB and cache write requires recovery |
The strategies are not mutually exclusive. Production systems layer them: write-through for high-value keys (inventory, session tokens) + TTL as a safety net + event invalidation for price or availability data. The TTL safety net ensures that even if an event is dropped, stale data eventually expires rather than persisting indefinitely.