Someone Told Me ‘Just Add Cache’, Here’s What Actually Happened

In this era, it’s incredibly easy to take a wrong turn. Large language models answer with confidence, and that confidence tends to spill into human conversations. People, regardless of their actual experience, can end up suggesting architectural decisions they aren’t equipped to evaluate. “Just add cache” is one of the most common oversimplifications.

We’re running an application with multiple instances on Kubernetes, and like everyone else who has done horizontal scaling, we have Redis as a shared component.

A while ago, I used to think Redis was a universal speed booster. It’s RAM, it’s fast, it must make everything faster. Right?

Not quite.

Redis doesn’t magically lower latency. Redis doesn’t fix poorly shaped data. Redis doesn’t improve performance if the root problem is upstream. In most real systems, Redis is used to keep distributed instances in sync and reduce repeated heavy work, not as a silver bullet for slowness.

And this is where the misconception hits hardest.

If your JSON payload is massive, especially when it crosses into multi-MB territory, pushing it into Redis won’t save you. You aren’t reducing cost, you’re just relocating it. The biggest penalty stops being storage access, and becomes the unavoidable JSON.parse overhead in your application.

Parsing a huge structure costs far more CPU time than whatever micro-latency Redis saves by being in RAM. You trade one bottleneck for another, and the system doesn’t actually get faster. It can even get slower due to network overhead, replication load, memory pressure, and throughput degradation.

In short, caching works when the data is small, stable, and cheap to serialize. Caching giant blobs is not optimization, it’s misdirection.