Systems

TTL and a prayer is not a strategy

First published on LinkedIn · 287 reactions

Cache invalidation is one of the two hard problems in computer science. Most engineers solve it with a five-minute TTL and a prayer.

Fixed TTL works for data that barely moves. For everything else you need a strategy, not a default.

1. Cache-aside

The common path. The app checks the cache first. Hit, return. Miss, hit the database, write the cache, return. Simple. Covers maybe 80% of cases.

The cost: between the database update and expiry, the data is stale. If that matters, you need active invalidation. Hoping the clock is kind is not a plan.

2. Write-through

Every write goes to the database and the cache at the same time. The cache stays current. Every write is slower, because you pay twice. Worth it when reads dwarf writes.

3. Write-behind

Write hits the cache first. Persistence to the database is async. Write latency is tiny. If the cache dies before flush, you lose data. I use this with caution, usually for metrics and counters, never for money.

4. Event-driven invalidation

When the row changes, an event fires and the cache is killed on purpose. Redis pub/sub or Postgres CDC. Fresh without waiting for TTL. More moving parts. Honest about freshness.

5. Stale-while-revalidate

Return the cached value immediately, even if it is expired, and refresh in the background. The user always gets a fast answer. The number might be thirty seconds late. Fine for dashboards, lists, anything where eventual consistency is acceptable.

Traps I refuse

Cache stampede

Thousands of requests arrive, the key just expired, all of them hit the database. Lock the rebuild. One request reconstructs. The rest wait or serve stale.

Caching data that changes every request

Serialize, store, deserialize. Often slower than going to the database. Cache only earns its keep at a high hit rate.

Cache with no hit-rate number

If you cannot see the hit rate, you do not know if the cache is helping or burning CPU for theater.

Pick the pattern for the data, not the pattern you memorized in a blog post. TTL is a tool. It is not a personality.