The Five-Minute Rule: A Heuristic for Deciding What Belongs in Cache

TL;DR: The “five-minute rule” is an old database heuristic that says: cache something if the cost of keeping it in memory is lower than the cost of re-fetching it, given how often it gets used. The actual “five minutes” number from the 1980s doesn’t matter anymore — what still matters is the thinking behind it: compare how often data is reused against how expensive it is to regenerate, and let that ratio (not a gut feeling) decide what you cache.

What is the “five-minute rule,” really?

It’s a simple test for deciding whether a piece of data is worth keeping in a fast, expensive place (memory) instead of a slow, cheap place (disk, or a database query, or a remote API call).

The original version, from database research in the late 1980s, worked like this: compare the price of storing one page of data in memory for a given stretch of time against the price of reading that same page from disk once. If the data gets reused more often than that break-even point, memory wins. If it doesn’t, disk is cheaper. When the researchers ran the math for the hardware of that era, the break-even point happened to land around five minutes between accesses — hence the name.

You don’t need the original math to use the idea today. The useful part is the shape of the question: how often is this data reused, versus how expensive is it to get it again? That single question is the heuristic. Everything else is detail.

Where does this idea come from, and why should I care if I’m not building a database?

Jim Gray and Franco Putzolu described it in a 1987 paper while thinking about how database engines should manage memory. But the underlying trade-off shows up anywhere you’re deciding what to cache: API responses, computed reports, rendered pages, search results, even DNS lookups.

You should care because most caching decisions in real teams get made by instinct instead of by this kind of comparison. Someone says “this endpoint feels slow, let’s cache it,” and the team adds a cache without ever asking whether the data is reused often enough to justify the complexity a cache adds — extra memory, staleness bugs, invalidation logic, and one more thing that can silently break.

How do I actually apply this at the application level?

Picture a mid-size online store. The product page pulls two kinds of data: the product’s description, images, and specs (which barely ever change), and the current stock count (which can change every few seconds during a sale).

Apply the heuristic separately to each:

• Product description/specs: read constantly (every page view), changes rarely (maybe once a month). Reuse is extremely high relative to the cost of refetching. This is an easy “cache it,” and you can cache it for a long time.
• Stock count: also read constantly, but changes constantly too. The “reuse” here is reuse of a value that’s already stale by the time you reuse it. Caching this for even 30 seconds during a flash sale means showing people stock numbers that are wrong. The heuristic says: the cost of being wrong (overselling, refunds, angry customers) belongs in the “cost of refetching” side of the equation, not just server load. Once you count that cost, a short cache or no cache at all usually wins.

Notice what happened: the same page produced two different caching decisions, because the question was asked separately for each piece of data instead of once for “the whole endpoint.”

What does the actual flow look like, cache hit versus cache miss?

It helps to see the two paths side by side. A cache hit skips the expensive step entirely; a cache miss pays the full cost and then (usually) saves the result for next time.

A cache hit answers in one cheap step. A cache miss pays the database cost, then stores the result so the next request doesn’t have to.

What does it look like when a team skips this and learns the hard way?

This is the part that usually convinces people. A team notices their product page is slow, so they cache the entire response — including the stock count — for five minutes, because “five minutes” sounded like a safe, standard number (it isn’t the same five minutes, but nobody checks). Nothing goes wrong until a flash sale, when 200 units sell out in ninety seconds. For the next three-and-a-half minutes, the cached page keeps telling shoppers the item is in stock. Orders come in for stock that doesn’t exist. Support has to apologize and issue refunds. The postmortem’s real finding isn’t “caching is bad” — it’s “we cached a fast-changing number using a rule built for slow-changing data.”

The journey below shows how that experience actually feels for the person debugging it, step by step.

The pain isn’t the caching itself — it’s applying one cache rule to data with two very different reuse patterns.

Doesn’t the actual “five minutes” number matter? Hardware is wildly different now.

It matters for the history, not for your decision today. Memory is far cheaper relative to disk and network calls than it was in 1987, and the exact break-even point has shifted accordingly — and it’s different again depending on whether “refetching” means a disk read, a database query, or a call to a third-party API across the internet.

That’s exactly why you shouldn’t borrow the literal number. Instead, borrow the method: figure out roughly how often a given piece of data is accessed, estimate what it costs (in time, money, or risk) to regenerate it each time, and compare. You don’t need a precise formula — even a rough gut-check using this framing beats picking a cache duration because it “felt reasonable.”

What are the most common mistakes teams make when they try to apply this?

A few show up again and again:

• Treating a whole endpoint as one unit. As in the store example, different fields inside the same response often have completely different reuse-versus-cost profiles. Cache them separately when you can.
• Forgetting that “cost of refetching” includes correctness, not just speed. A stale price or stock count isn’t just a slightly outdated number — it can cost real money or trust. That risk belongs in the cost side of the comparison.
• Picking a cache duration first and asking questions later. “Let’s cache it for five minutes” should be the output of the reasoning, not the starting point.
• Never revisiting the decision. Access patterns change. A field that was read-heavy and rarely updated last year might not be this year. The heuristic is worth rerunning when traffic patterns shift, not just applied once at launch.

How is this different from just “cache everything you can get away with”?

“Cache everything” treats caching as free, so more is always better. The five-minute rule treats caching as a trade: you’re spending memory, complexity, and risk of staleness in exchange for not re-doing expensive work. Sometimes that trade is a clear win. Sometimes — like the stock-count example — it’s a bad trade dressed up as an optimization.

The heuristic doesn’t tell you to cache less or cache more. It gives you a concrete question to ask before you reach for a cache at all: is this data reused often enough, relative to how expensive and how risky it is to regenerate, that keeping a copy around actually pays for itself? If the answer is yes, cache it with confidence. If the answer is no, you’ve just avoided a bug that would otherwise have shown up during your busiest week.