Cache Consistency Strategies: Cache Aside Pattern, Deleting vs Updating Cache, and Queue‑Based Solutions for High Concurrency

Distributed caching is essential for many applications, but it introduces data consistency challenges when using a cache alongside a database.

Cache Aside Pattern

The classic read/write approach reads from the cache first, falls back to the database if missing, stores the result in the cache, and on updates writes to the database then deletes the cache entry.

Why Delete Cache Instead of Updating?

Complex cache values may depend on multiple tables or expensive calculations; deleting the cache avoids costly recomputation and follows a lazy‑loading principle, updating the cache only when it is actually accessed.

Basic Cache Inconsistency Problem and Solution

If the cache is deleted then the database update fails, stale data remains in the cache. The safer order is to delete the cache first, then update the database; a failed database write leaves the cache empty, forcing a fresh read.

More Complex Inconsistency Scenarios

In high‑traffic environments, concurrent reads and writes can cause a race where a read sees stale data after a cache delete but before the database commit, leading to inconsistency.

Proposed Queue‑Based Solution

Route all update and read‑miss operations through a JVM internal queue per data item. A single worker thread processes operations sequentially: delete cache, update DB, then on subsequent reads fetch fresh data and repopulate the cache.

Optimizations include deduplicating consecutive cache‑update requests in the queue and monitoring queue length to avoid long read‑blocking times.

Potential Risks in High Concurrency

Read requests may block if the queue is saturated; timeouts must be enforced, and load testing is required to size the number of queues and service instances appropriately.

Routing all requests for the same key to the same service instance (e.g., via Nginx hash) helps maintain ordering, while hot‑item skew may require additional sharding.