“Let's add a cache” sounds like a small engineering task. Repeated requests reuse a prepared answer, the database does less work and pages load faster. Then a price changes, and support has to explain why the catalogue and checkout disagree. That conversation belongs in the cost estimate too.
A cache stores a result for reuse instead of fetching or computing it again. It may live in the application, browser or an intermediate service. The management question is not where to put it first. It is which expensive work disappears and where an old answer could cause trouble.
Find the expensive work first
A popular product description is read repeatedly and changes infrequently. Reusing it has an obvious purpose. A personalised report with different filters on every request may hardly ever repeat. Saving every result can cost more than a demonstration of one successful cache hit suggests.
Establish a baseline: request latency, time spent in the database and the frequency of equivalent requests. Check the query and its indexes too. Improving one expensive query may be easier than maintaining another copy of its output indefinitely.
After deployment, a high hit rate is not enough. If most hits serve cheap requests while costly queries still reach the database, the headline metric says little about the saving. Compare meaningful user actions, source load and the operating cost of the whole arrangement.
A price and a product photograph age differently
A brief delay in updating a photograph may have little consequence. A stale stock count can lead the product to promise an unavailable item. Browsing may use cached availability, while the actual reservation must validate the sale against the system that owns inventory.
This is a distinction between displaying information and acting on it, not a blanket ban on caching important data. Decide where an approximate view is acceptable, where current validation is required and what the customer sees if something changes between browsing and confirmation.
Access permissions deserve separate treatment. After an employee is blocked, an old “access allowed” result is more dangerous than an outdated picture. It needs an appropriate lifetime and revocation mechanism, not the catalogue's default cache settings.
Expiry is not an end-to-end freshness guarantee
A cached entry commonly has a time to live, or TTL. That interval starts when the entry is stored, not necessarily when the underlying information last changed. Populate a cache from a lagging replica and it can contain stale data from its first moment. Additional cache layers make freshness harder to reason about.
Invalidating an entry after an update is not an absolute guarantee either. A reader may start before the change, obtain an older value and write it to cache after invalidation. Version checks, coordinated updates or a different design may be needed for the particular operation.
The Cache-Aside pattern documentation explicitly distinguishes this technique from a consistency guarantee. For an important operation, “we clear the cache regularly” is not sufficient: the product needs a tested freshness requirement and a defined response when it cannot be met.
The load returns when the cache disappears
After a restart or widespread expiry, requests return to the source. A database that normally handles only cache misses may not cope with the entire workload. If every miss starts an expensive calculation, one popular item can generate many identical jobs.
Possible controls include sharing one refresh among concurrent readers, warming popular entries, spreading expiry times and limiting requests to the source. Briefly serving older data during refresh may be acceptable for some information. It needs very different treatment for revoked permissions or payment confirmation.
Test this behaviour under load rather than discovering it during an outage. Microsoft's caching guidance discusses refresh, distributed copies and consistency limitations.
One customer's answer must not become everyone's answer
If a price depends on customer, currency or contract, the cache key must distinguish the inputs that change the result. Otherwise one tenant may see another's negotiated terms. Authorisation remains necessary: an appropriate key is not an access-control system.
Start with one measurable use case. Test normal traffic, a source update, a completely empty cache and an unavailable source. Inspect what the screen says as well as how quickly it loads. Only then extend the approach. Clearing everything without controlling the returning database load is a poor recovery plan, even if it happened to work last time.