When to Replace In‑Process Cache with Redis? A Practical Guide

Overview

Cache can be divided into two categories: 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.

In‑Process Cache

In‑process cache stores data inside the application’s process memory. Historically it was widely used, for example the .NET System.Web.Caching class. Implementation is simple—a locked hash table or list that can hold HTML fragments, files, or any objects.

In a monolithic web model, developers push process cache to its limits, as shown in the diagram below.

Compared with no cache, process cache avoids direct database hits: the system first checks the cache, reads from it if present, otherwise queries the database and then writes the result back to the cache. This reduces network traffic, lowers request latency, and effectively executes reads in memory.

Cache is most valuable for cold data that changes infrequently, such as system dictionaries or configuration data. Real‑time hot data (e.g., a user's step count) gains little from caching.

Problems with In‑Process Cache

When traffic grows and the system moves to a clustered, multi‑instance deployment, the limitations of process cache become evident:

Cache cannot be shared across instances, leading to consistency issues.

Each node maintains its own copy, making data synchronization difficult.

Typical solutions include:

Single service node notifies other nodes after updating the database and its own cache.

Use a message queue (MQ) to broadcast cache‑update events to all nodes.

Deploy an independent background process that periodically pulls the latest data from the backend and refreshes the in‑memory cache, sacrificing real‑time consistency.

These approaches add synchronization overhead and introduce risks of inconsistency or errors. Moreover, frequent cache updates undermine the core purpose of caching—isolating cold data to relieve database pressure.

Therefore, in the following scenarios it is advisable to abandon process cache and adopt an external cache service:

Web clusters with multiple instances where data inconsistency is unacceptable.

When the volume of cached data exceeds the memory capacity of a single process.

When evaluation of value size, memory limits, peak QPS, expiration policies, hit rates, read/write strategies, key distribution, and consistency requirements indicates a cache service is more suitable.

Cache Service (Redis)

Redis is the most widely used key‑value cache service in modern internet architectures. Its main characteristics are:

1. Supports Complex Data Structures

Values can be strings, hashes, lists, sets, or sorted sets, enabling use cases such as order lists, user messages, and comment threads.

2. Persistence Options

Data is kept in memory and periodically persisted to disk (RDB snapshots) or logged to an Append‑Only File (AOF). Full persistence incurs performance overhead, so Redis is typically used as a cache rather than a primary database; persistent data should still be stored in a relational database.

3. High Availability

Redis supports clustering, replication, read/write splitting, and provides Sentinel for monitoring and automatic failover.

4. Large Storage Capacity

String values can be up to 512 MB; collections can hold up to 2³²‑1 elements (~4.3 billion).

5. Transaction Support

All operations are atomic, ensuring either full execution or none, which helps maintain data consistency.

Cache Usage Tips

After migrating from monolithic to multi‑instance deployment, replace all process‑level caches with Redis calls. Be aware of the following pitfalls:

Missing a few cache updates can cause stale data to appear intermittently across instances.

Guard against cache‑penetration and cache‑avalanche scenarios; these require separate analysis.

By following these guidelines, developers can design a robust caching layer that improves performance while maintaining data consistency.