Benjamin Cane
Portrait of Benjamin Cane
Benjamin Cane
July 30, 2026
performance
a very large array of electronic equipment in a room
Photo by Matthieu Beaumont on Unsplash

Caching isn’t hard. Some data is hard to cache.

You’ve all heard the advice: “Avoid caching because caching is difficult to get right.”

I agree with part of that statement. Caching can absolutely be difficult. But I think the reality is more nuanced.

The difficulty level of caching depends heavily on the type of data you are caching.

Not All Data Is Equal

When engineers talk about caching complexity, they’re usually thinking about data that changes frequently and requires strong consistency.

That’s the hardest kind of data to cache. Because you need to answer some difficult questions.

  • How do you invalidate the cache?
  • How do you handle updates?
  • What happens when the cache population fails?
  • How stale is too stale?

These problems are real, but they don’t apply to all data.

Frequently Updated Data

Some data changes constantly and has strict accuracy requirements. Account balances, inventory counts, active orders, and similar records. This is where caching is difficult.

Every stale read has a consequence, and in some cases, it’s not worth the complexity.

Infrequently Updated Data

Some data changes occasionally, once an hour, once a day, or even longer. Configuration data, product catalogs, country codes, and similar records.

In these cases, a small amount of staleness might be fine. If data changes hourly and your cache refreshes every few minutes, that’s often a reasonable tradeoff. The less frequently data changes, the less sensitive you become to cache staleness.

Caching is much easier with infrequently updated data.

Immutable Data

Immutable data is the easiest to cache. Because it never changes. Ledger entries, event records, receipts, and other immutable records.

Once immutable data is loaded into a cache, cache invalidation largely disappears as a problem. Cache complexity for immutable data is more about balancing performance and hit-miss ratios.

Most of the time, immutable data is an ideal candidate for caching.

The Real Question

Instead of asking, “Should I cache?” Ask yourself, “How often does this data change? How accurate does it need to be?”

The answers will give you an idea of how complex caching will be.

Final Thoughts

Caching isn’t inherently hard.

Maintaining correctness for frequently changing data is hard.

The more stable the data, the less complex the caching needs to be.

Like most things in system design, you can’t just take all-or-none answers like “always cache” or “never cache.” It’s important to understand the trade-offs, constraints, and consistency requirements of the data you’re working with.

Discuss on LinkedIn Newsletter Back to all posts

More to Read

  • July 23, 2026 The closer to the edge, the more stable a platform must be reliability
  • July 16, 2026 Sometimes the most resilient thing a system can do isn’t retry reliability
  • July 9, 2026 Should retries and timeouts live in your application or your service mesh? reliability
  • July 2, 2026 Need to migrate from one database to another without downtime? architecture
  • June 25, 2026 Glue Services: Part Two — Data Synchronization architecture

Practical engineering notes by Benjamin Cane.