Cache Aside Pattern and Solutions for Cache‑Database Consistency in High‑Concurrency Environments

Distributed caching is essential for many modern applications, but using it introduces cache‑database dual‑write consistency challenges.

Cache Aside Pattern

The most classic read‑write model combines cache and database: on a read, the cache is checked first; if missing, the database is queried, the result is stored in the cache, and the response is returned. On an update, the database is updated first, then the cache entry is deleted.

Why Delete Cache Instead of Updating It?

In complex scenarios the cached value may be derived from multiple tables or expensive calculations, making direct cache updates costly. Deleting the cache and recomputing lazily when needed reduces overhead, especially when the data is rarely read after a rapid series of updates.

Basic Cache Inconsistency Problem and Solution

If the cache is deleted after the database update and the delete fails, the cache holds stale data. The remedy is to delete the cache first, then update the database; if the database update fails, the cache remains empty, preventing inconsistency.

Analysis of More Complex Inconsistency Scenarios

When a write deletes the cache, then a read arrives before the database update completes, the read may fetch stale data from the database and repopulate the cache, leading to divergence after the write finishes. This issue becomes pronounced under high‑concurrency, high‑traffic conditions where many reads and writes occur simultaneously.

Proposed Solution

When updating data, route the operation (identified by a unique key) to an internal JVM queue. Reads that miss the cache also send a “populate‑cache” request to the same queue. Each queue is serviced by a single worker thread that processes operations sequentially: delete the cache, then update the database; for reads, after the database value is fetched, the cache is refreshed.

The queue can filter duplicate cache‑populate requests to avoid unnecessary work. If a read request waits beyond a configurable timeout, it falls back to reading the current (possibly stale) value directly from the database.

1. Read Request Long‑Running Blocking

Because reads are lightly asynchronous, they must respect timeout limits. Excessive write frequency can cause the queue to backlog, leading to many read timeouts and a surge of direct database traffic. Proper load testing is required to size the system.

2. High Read Concurrency

Stress testing should verify that the service can handle spikes of concurrent reads without excessive latency, ensuring that only a limited subset of data experiences cache misses at any moment.

3. Request Routing Across Multiple Service Instances

When multiple instances are deployed, updates and corresponding cache operations must be routed to the same instance (e.g., via Nginx hash routing) to preserve ordering guarantees.

4. Hot‑Item Routing and Load Skew

If a particular item receives a disproportionate number of read/write requests, its queue may become a bottleneck. Distributing hot‑item traffic across multiple queues or machines can mitigate this risk.

Overall, the solution relies on a per‑key serialized processing queue to guarantee cache‑database consistency while minimizing unnecessary cache recomputation.