Caching is the easiest performance win in any item, and the easiest way to generate support tickets that read "I changed the price and the old one is still showing".
Decide what invalidates each thing
Before you cache anything, write down what makes it wrong. A product listing is invalidated by a product changing. A settings value by settings being saved. If you cannot name the event, you cannot clear it correctly and you should not cache it.
Clear on write, not on a timer
Time-based expiry means every change is wrong for up to that long. Clearing when the underlying thing is saved means it is never wrong. Use a timer as a safety net, not as the mechanism.
Put a version in the key
Include something that changes when your data shape changes. Then an update that alters what a cached structure looks like cannot serve the old shape to new code, which is a spectacular and confusing failure otherwise.
Never cache anything user-specific under a shared key
The most serious caching bug is one buyer's data served to another. Anything that varies by who is logged in either includes the user in the key or is not cached at all.
Give them a clear-cache button
In settings, obvious, with a note saying it is safe. It turns a mysterious problem into something the buyer fixes themselves in ten seconds, and it is the first thing you would ask them to do anyway.
Let it be switchable
Some hosts behave oddly. A setting that disables caching entirely gives you a clean way to isolate a problem remotely without shipping a debug build.
