Time as a Dependency

Caching appears simple: store something once, reuse it later. In reality, caching introduces time as a dependency—and time is one of the hardest things to reason about in systems.

Caching is often added reactively, as a response to performance problems. This improves latency temporarily while increasing system complexity long-term.

Caches change system behavior. They alter load patterns, consistency guarantees, and failure modes. A system that works without caching can fail dramatically once caching is added incorrectly.

Invalidation is the real problem. Knowing when cached data becomes wrong requires deep understanding of data ownership and mutation paths. Without that understanding, caches silently serve lies.

Some caching principles I trust:

• Cache derived data, not source-of-truth data
• Design for cache misses, not cache hits
• TTLs are safety nets, not correctness tools
• Assume caches can be empty at the worst moment
• Prefer explicit invalidation over clever heuristics

Caching intersects heavily with [[System Design]]. Cache stampedes, cold starts, and uneven traffic spikes are architectural problems, not configuration issues.

Caching also distorts observability. Cached systems may look healthy while underlying dependencies degrade. When caches fail, failures are sudden and severe.

Caching is powerful, but it demands discipline. Speed without correctness is just fast failure.