Most advice about caching stops at "add Redis" or "add Memcached," as if one layer solves every caching problem an application will ever run into. Looking back at our own systems, mature applications usually need two layers that solve two different problems. A fast, short lived, in memory cache for the reads that happen constantly, and a slower, lasting, file or disk backed cache for values that cost a lot to work out but do not need to answer in a single millisecond.
An in memory cache, Memcached, Redis, or something similar, is the right place for data that gets read constantly and changes often enough that you do not want it surviving a server restart by accident, things like session lookups, dashboard queries that get hit all day, or computed option lists. A lasting, file based cache is better suited to values that are genuinely expensive to work out again and do not need to disappear just because a server restarted, a generated report, a built configuration, a reference set of data that rarely changes. Treating both of these as simply "the cache," and reaching for whichever one happens to be set up, leads to quiet bugs, a restart that silently makes the application slow, or a value that should have disappeared quickly instead sitting around for months.
The single hardest problem in caching has never been storing the data. It is knowing exactly when to throw it away. The pattern that actually holds up is tying every cache write to the database tables it depends on, so a write to any of those tables clears the cached value immediately, without the developer writing that particular query having to remember to clear a cache by hand. A cache that depends on developers remembering to clear it manually is a cache that will, sooner or later, serve old data in production. We have learned this is not a maybe. It is a certainty.
If you offer a permanent cache tier, one that survives a restart, be deliberate about what is actually allowed into it. It should only hold values that always come out the same way given the same input, and that are genuinely expensive to work out again, never used as a general fix for a slow query that should simply have a proper index instead. A lasting cache hiding a missing index is a problem put off, not solved. The day that cache gets cleared, the application falls over, and we have watched this happen.
Adding a cache and never checking whether it is actually being hit is common, and it hides two opposite problems at once, memory spent on values nobody reads twice, and a busy path that should be cached but is not. We now treat cache hit rate as a number worth watching on a dashboard, the same way we watch error rate or response time.
Maybeach Tech designs caching strategies that hold up under actual production load, not made up tests. Get in touch and tell us about your performance bottlenecks.
