When to Choose Process Cache vs Redis: A Practical Guide for Scalable Systems

Overview

Cache can be divided into in‑process (internal) cache and external cache services such as Redis or Memcached. As applications evolve from monolithic to multi‑instance and microservice architectures, external cache services become increasingly popular.

Process Cache

Process cache stores data inside the web service’s process. Historically it was widely used, for example the .Net System.Web.Caching. Implementation is simple, often a locked hashtable or list, and can store data, HTML fragments, files, or any objects.

In a monolithic web model, process cache was heavily utilized to avoid database hits: data is read from cache if present, otherwise fetched from the database and then written to cache, reducing network overhead and improving read efficiency.

Cache is most valuable for cold‑hot data separation; frequently changing data (e.g., real‑time step counts) gains little from caching, while large, rarely modified data such as system dictionaries or configuration values benefit greatly.

When to create cache: Evaluate data change frequency—if updates are too frequent, cache rebuilds may degrade performance. A practical rule is that unchanged data should exceed 60% of the cache’s expiration window.

Assuming a cache TTL of 3600 seconds and 6000 items of a given type, if 3600 items remain unchanged within an hour, caching those items is worthwhile.

Problems with Process Cache

As user volume grows and services shift to clusters, the drawbacks of process cache become evident, especially consistency issues when multiple nodes maintain separate caches.

Solutions include:

Single service node notifies other nodes to update their caches after a database change.

Using a message queue (MQ) to broadcast cache invalidation events to all nodes.

Running an independent process that periodically pulls fresh data and refreshes in‑memory caches, sacrificing real‑time consistency.

These methods add synchronization overhead and risk errors, potentially violating the principle of separating hot and cold data.

Therefore, we abandon process cache in the following situations and adopt an external cache service:

Web clusters with multiple instances where business data inconsistency is unacceptable.

Large in‑process cache size that exhausts memory and harms performance.

When evaluating value size, memory, peak QPS, TTL, hit rate, read/write strategy, key distribution, expiration policy, and consistency requirements suggests an external service.

Cache Service

Redis is the most common key‑value cache in internet‑scale architectures. Its key features include:

1. Support for complex data structures

Values can be strings, hashes, lists, sets, or sorted sets, suitable for orders, messages, comments, etc.

2. Persistence options

Data resides in memory and is periodically saved to disk (RDB snapshots) or logged via an Append‑Only File (AOF). However, Redis should not replace a primary database; for durable storage, use MySQL.

3. High availability

Redis offers native clustering, replication, read/write splitting, and Sentinel for monitoring and automatic failover.

4. Large storage capacity

String values can be up to 512 MB; lists, sets, and hashes can hold up to 2³²‑1 elements.

5. Transaction support

Operations are atomic, ensuring either full execution or none, which prevents data inconsistency.

Cache Usage Tips

When migrating from a monolithic to a multi‑instance deployment, replace all process caches with Redis. Missed replacements can cause intermittent stale data across instances.

Be vigilant about cache‑penetration and cache‑avalanche scenarios; these issues merit dedicated analysis.

Source: https://www.cnblogs.com/wzh2010/p/13874206.html