The cache lifetime your config.xml is lying about
A module documented a ten minute price cache. It was really running at twenty four hours, and nothing invalidated it when prices changed.
Somebody asked a reasonable question about a shop I work on: how fresh are the prices on the product page? The module had a cache, the cache had a lifetime, and the lifetime was in the module's own config.xml as 600 seconds. Ten minutes. That was the answer I nearly gave.
The real answer was up to twenty four hours.
Two things were wrong
The first is ordinary and everyone knows it in the abstract. A value in config.xml is a default, and defaults lose to whatever is in the database. Somebody had set the lifetime to 86400 in core_config_data long enough ago that nobody remembered. The XML said one thing, production did another, and reading the module told you nothing useful.
SELECT path, value FROM core_config_data
WHERE path LIKE 'yourmodule/cache%';The second is worse. I went looking for the code that clears this cache when a price import runs. There is none. The cache type was referenced in exactly two places, both inside the caching classes themselves, and the import never touched either. So a price change from the ERP did not reach the storefront when the import finished. It reached the storefront when the day rolled over, or when somebody flushed that cache type by hand.
Why nobody noticed
Because it mostly looks fine. Prices do update, just later than anyone thinks. On a shop where prices move once a week, a twenty four hour lag is invisible. On a shop where somebody is on the phone asking why the site still shows the old price, it is the whole problem, and the person debugging it will read the same config.xml I did and conclude the cache cannot possibly be the cause.
What to actually check
Read the value from the database, never from the XML. The XML is the default, not the setting.
Grep for the cache type identifier across the whole codebase, not just your module. If the only hits are the class that writes the cache and the class that reads it, nothing invalidates it.
Then ask what is supposed to invalidate it, and go and find that code. If you cannot find it, it does not exist, and your cache lifetime is your data freshness guarantee.
The honest answer to "how fresh are our prices" turned out to be "up to a day, and we cannot tell you when it last changed". That is a fine answer. It just was not the one anybody expected, and it changed the design decision it was blocking.