How to Solve Distributed Cache Consistency Issues with Lazy Updates and Queues

Cache Aside Pattern

The most classic cache‑plus‑database read/write model is the Cache‑Aside pattern. When reading, the system first checks the cache; if the cache misses, it reads from the database, returns the data, and stores it in the cache. When updating, the database is updated first, then the cache entry is deleted.

Why delete the cache instead of updating it? In complex scenarios the cached value may be derived from multiple tables, and recomputing it can be expensive. Deleting the cache defers the costly computation until the data is actually needed, following a lazy‑calculation principle similar to lazy loading in ORM frameworks.

Basic Cache Inconsistency Problem and Solution

Problem: Update the database then delete the cache. If cache deletion fails, the cache holds stale data, causing inconsistency.

Solution: Delete the cache first, then update the database. If the database update fails, the cache remains empty, so reads fall back to the database’s old data and then refresh the cache.

Analysis of More Complex Inconsistency Scenarios

When a data change triggers cache deletion before the database update, a concurrent read may find the cache empty, fetch the old database value, and repopulate the cache with stale data. This leads to divergence between cache and database, especially under high‑traffic, high‑concurrency workloads.

Proposed Queue‑Based Lazy Update Solution

During an update, route the operation (identified by a unique key) to an internal JVM queue. Reads that miss the cache also enqueue a cache‑refresh request. Each queue is serviced by a single worker thread that processes operations sequentially: delete the cache, wait for the database update to complete, then read the latest value and write it back to the cache.

The queue can filter duplicate cache‑refresh requests, ensuring only the latest update is applied. If a read request waits too long, it can fall back to reading the current (possibly stale) database value.

Key Considerations for High‑Concurrency Environments

1. Read request latency – Because reads may be blocked while waiting for the queue, time‑outs must be enforced and the system stress‑tested to avoid excessive latency.

2. Read request volume – Sudden spikes in read traffic can cause many requests to hang; capacity planning and load testing are essential.

3. Consistent routing to the same instance – Updates and corresponding cache‑refresh operations should be routed to the same service instance (e.g., via Nginx hash routing) to preserve ordering.

4. Hot‑item skew – Hot keys may overload a single queue or instance; sharding queues or deploying more instances can mitigate this.