Caching is one of the most powerful and most misunderstood tools in system design. Teams often start by comparing Redis, CDN edge caches, and in-memory stores. The better place to start is with the rules the cache must enforce.

Where should a cache make its decisions?

Choose a cache layer according to what it needs to know about the response, rather than treating edge and application caching as interchangeable.

• Edge caches are excellent for static assets that do not vary by user or region. They are less useful when responses depend on authentication, personalization, or rapidly changing data.
• Application caches can use business knowledge to decide what to store and when to evict, but they add complexity closer to the code.
• Database query caches help when the same expensive query is run repeatedly, but they can hide stale data if invalidation is not thought through.

The right layer depends on the access pattern, not on which tool is newest.

Design invalidation before choosing a cache store

A cache design needs clear answers to three questions before the storage technology matters:

1. Identity: what variations belong in the same cache key? User ID, locale, and role often matter. Combining them incorrectly either wastes space or serves the wrong content.
2. Freshness: how long can data live before it becomes misleading? Different data has different update patterns. Product prices and inventory levels need different rules than marketing copy.
3. Invalidation: how do you remove or refresh an entry when the source data changes? Event-driven invalidation, time-to-live, and manual purge each have trade-offs.

If you cannot answer these three questions, the cache store you choose will not save you from stale or inconsistent data.

A practical checklist

• Define the cache key and every dimension that affects it
• Set explicit freshness rules per data type
• Choose an invalidation mechanism that matches your update pattern
• Monitor cache hit rate and stale-data incidents separately
• Document the cache as a system contract, not as an implementation detail

When caching is designed around identity, freshness, and invalidation, the storage choice becomes straightforward.