Caching Without Regret

People like to joke that cache invalidation is one of the two hard things in software. I am not sure it is hard so much as fuzzy. We rarely write down who can tolerate being wrong, by how much, and for how long. So we guess a TTL, someone bumps it during an incident, and a month later, nobody remembers why the numbers feel off. I have done that. More than once.

This is a calmer route. Not perfect. Practical. You will get a small decision card you can paste in a repo, a few defaults that hold up in production, and a couple of places where I tripped before you have to. It also connects to earlier lessons. Backpressure helps when serving stale is the safest answer. SLOs turn staleness into a contract. Idempotency makes background refreshes safe.

From cache as a speed knob with a guessed TTL
To cache as an explicit staleness contract tied to what a user feels

A cache is not magic. It is a promise with a clock on it. The real question is not “how long should the TTL be”. It is “who can tolerate being slightly wrong, by how much, and for how long”. Once you say that out loud, choices get less dramatic.

Helpful inversions to keep nearby
• Hit ratio is not the hero. Staleness, you can explain. A lovely ninety-five percent hit ratio can still feel terrible if the five percent misses stampede the origin. Track age buckets and how many regenerations you coalesced.
• Global TTLs create quiet lies. Per-flow staleness budgets make sense. A product tile can be thirty to sixty seconds stale, and nobody blinks. Cart totals cannot. Write two numbers. Adjust later.
• “Purge everything on write” feels safe and burns money. Event or webhook-driven invalidation is kinder. Keep a small TTL as a guardrail.
• Blocking everywhere for fresh data slows the whole page. Stale-while-revalidate is the default for many views. For money and trust areas, such as cart totals, stay strict and skip SWR.
• Fuzzy keys cause crosstalk. Keys should match reality. Tenant, locale, currency, device class, and personalization flags. If it changes the view, it changes the key.
• Caching errors forever laminates a shrug. Brief negative caching with jittered retries quiets hot misses without hiding real issues.

You will still be wrong sometimes. That is fine. The win is moving from accidental staleness to intentional and measured staleness that you can show on a dashboard and revise without drama.

If this resonated, the new version of my free 5-Day Crash Course – From Developer to Architect will take you deeper into:

It’s 5 short, focused lessons designed for busy engineers, and it’s free.

👉 Join the 5-Day Crash Course Here »

Now let’s continue.