Why You Should Minimize Local Cache Usage

My guiding principle is simple: if a database can handle the load, never use a cache; if a central cache (e.g., Redis) suffices, never add a local cache. This reflects a broader software design rule—reduce dependencies to lower management complexity.

If the database can bear it, absolutely avoid caching. If a central cache can bear it, absolutely avoid local caching.

Local caches introduce high maintenance costs because they must stay consistent with the database and any central cache across dozens of machines. Updating data requires notifying every instance; missing even one node can produce stale data, and network hiccups can cause inconsistency.

**Example 1:** In a product‑service system that faces a flash‑sale with millions of concurrent requests, we only enable local cache for the half‑hour of the promotion. During normal operation the cache remains disabled because keeping dozens of machines in sync is too hard.

**Example 2:** For a shopping‑cart service serving billions of users, we also turn on local cache only during brand‑driven campaigns or sudden traffic spikes. After the event we switch back to Redis alone, since Redis is already fast enough and the microsecond gains from local cache do not justify the added consistency risk.

Another often‑overlooked issue is garbage‑collection pressure. A heap‑resident local cache consumes JVM heap; if its size is not tightly controlled it can trigger Full GC pauses. Off‑heap caches are an option, but they require deep expertise—our team spent weeks researching and conducting multiple rounds of stress testing before we felt confident to deploy one.

The overarching recommendation is to keep optimizing the existing code until a genuine bottleneck appears, and only then consider adding a cache layer.