caching-strategies

Caching Strategies

Caching is one of the few changes that can make a system both faster and more fragile in the same commit. It is easy to add and easy to get subtly wrong, and the failure mode is rarely a crash — it is a user seeing data that is quietly, plausibly wrong, which is far harder to notice and debug than an error.

The decision to cache something is really two decisions: is this worth the complexity, and am I willing to accept the staleness this introduces. Skipping the second question is how caches turn into a source of bugs instead of a source of speed.

A cache without an explicit invalidation and staleness story is not an optimization — it is a bet that nobody will notice when the data is wrong.

1. Cache what is expensive and read-heavy, not everything

Every cached value is a second copy of the truth that can drift from the source, so caching should be reserved for data where the read cost or read frequency actually justifies that risk.

• Cache results that are expensive to compute or fetch — aggregations, joins across services, external API calls — not simple key lookups that are already fast.
• Cache data that is read far more often than it changes. A value read a thousand times between writes is a good candidate; a value read once per write gains little from caching.
• Skip caching data with strict consistency requirements, like account balances or inventory counts at checkout, unless the invalidation story is airtight.

Done when: each cached value has a stated reason — read frequency, compute cost, or upstream latency — that justifies the staleness risk it introduces.

2. Pick the pattern that matches your consistency needs

The three common caching patterns trade off differently between read speed, write speed, and staleness risk, and picking the wrong one for the workload is a common source of both bugs and wasted engineering effort.

Pattern	Reads	Writes	Risk
Cache-aside	App checks cache, falls back to source, populates cache	Simple, cache invalidated on write	Cache can go stale if invalidation is missed
Write-through	Always served from cache	Written to cache and source together, in sync	Write latency increases; cache always fresh
Write-behind	Always served from cache	Written to cache immediately, source asynchronously	Fast writes; risk of data loss if cache fails before flush