When to Use a Cache — The Trade-off Between Fast and Correct

The Trap in "Can You Make This Faster?"

One of the most common things a product manager asks a developer is "can this screen be faster?" And a frequent answer from the engineering side is a cache. "If we cache it, it gets faster." So far so good. The catch is that a cache isn't free. In exchange for speed, you also buy the risk that the data goes stale — old. So the real question isn't "cache or not" but when to use a cache and when to avoid one.

This post lays out how a product manager makes that call, at a level that needs no code. A cache is not just a developer's choice — it's a planning decision about how fresh the data has to be.

What a Cache Is — Keeping What You Use Often Close By

A cache isn't hard. It is a copy of what you use often, kept somewhere close. Instead of walking to the deep drawer (the origin database) every time, you keep a copy on the desk (a fast store) and use that. Responses get much faster.

Everyday life has caches too. Memorizing a password you use constantly instead of digging through a file each time, keeping frequently-used papers on your desk rather than in a drawer — all of it is the caching idea. Web services do the same. Rather than redoing heavy work or re-querying the database on every request, they hold a once-made result briefly and reuse it.

Why It Gets Faster, and Why It Goes Wrong

The benefit and the risk of a cache are two sides of one coin.

Why it's faster is clear: you skip the long trip to the origin and use the nearby copy. Saving one heavy computation and reusing it across thousands of people also eases server load.

Why it goes wrong comes from the same place. If the origin changes while the copy sits there, the cache still holds the old value. This is called stale data. Cache a product's price, and if the price rises in the meantime, users see the old one. Every cache incident boils down to one sentence — the origin changed, but the copy didn't.

When to Use a Cache

Data that fits a cache well has something in common: it is read often and changes rarely.

• Frequently read information: popular product lists, notices, the home screen layout — things many people view over and over.
• Rarely changing data: category lists, country and region codes, terms of service — things that barely change once a day.
• Heavy computed results: statistics, recommendation lists — expensive to build but valid for a while.
• Things that can lag a little: visitor counts, like counts — values users won't mind being a few seconds old.

For this data the benefit (speed) is large and the risk (stale) is small. Caching it is almost always a win.

When to Avoid a Cache

Conversely, some data is dangerous to cache: things that must always be accurate, or change moment to moment.

• Values where real-time accuracy matters: account balance, stock quantity, payment amount. Show an old value and it's an incident on the spot. Cache stock, and if it shows "available" when it's sold out, you get order failures.
• Personal data that differs per person: if one person's cache bleeds into another, A's information shows up for B — a major breach. Personalized data needs special care.
• Frequently changing data: a value that changes several times a second goes stale almost immediately, so the management cost outweighs the speed gained.

Here "don't be wrong" beats "be fast." If you must cache, keep it very brief, or design a mechanism that drops the copy the moment the origin changes.

What a Product Manager Should Decide — "How Fresh Must It Be?"

The key: the decision that makes or breaks a cache is not technology but a standard. What a product manager owns reduces to one thing — how fresh does this data need to be? Split that into three questions and the call gets easy.

Set the Tolerable Lag

"Can this number be five minutes old, or must it be real-time?" That single line is the starting point of a cache design. Five minutes tolerable → cache for five minutes; real-time required → don't cache, or refresh instantly. Don't just ask a developer for "faster" — hand over the tolerable lag as a number, and the conversation gets clear.

Decide When to Drop the Copy (Invalidation)

When the price changes, stock drops, a post is edited — the cache should be dropped at that moment. Miss this "invalidation point" and you get stale incidents. It helps to list, at the planning stage, which events should force the copy to refresh.

Size the Damage When It's Wrong

A like count being a few seconds off is charming; a balance being off is a disaster. The bigger the damage, the shorter the cache — or none at all. Weighing the speed benefit against the stale damage on one scale becomes your standard for the call.

These three are the same kind of call as setting up a fallback as a safety net — just as planning decides "what to show when things aren't normal," planning also decides "how fresh this must be."

In a Table — Data That Fits a Cache vs Data That Doesn't

Aspect	Fits a cache	Doesn't fit
Change frequency	changes rarely (categories, terms)	changes constantly (balance, stock)
Accuracy demand	a little lag is OK (view counts)	must always be accurate (payment amount)
Scope	same value for everyone	personal data, differs per person
Verdict	big cache benefit → use freely	big stale risk → brief or none

A Cache Is a Dial Between Fast and Correct

The answer to when to use a cache, in one line: a cache is not an on-off switch but a dial you turn between fast and correct. Turn it toward data that is read often, changes rarely, and can lag a little, and you win; on data that must always be accurate, turn the dial down.

And where to set that dial is a question of standards, not technology. If a product manager can clearly answer "how fresh does this data need to be," the developer designs a cache to match. Like idempotency preventing duplicates in payments and orders, it's an invisible decision that governs whether users trust the service. Next time, before you say "make it faster," ask yourself first: "how fresh does this actually need to be?"