Solving Distributed Cache Consistency: Cache‑Aside Pattern & Lazy Update Strategies

Cache Aside Pattern

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

Why delete the cache instead of updating it?

In many complex caching scenarios, the cached value is not a direct copy of a single database row but may require fetching and computing data from multiple tables. Updating such a cache can be costly, and if the data is rarely accessed, repeatedly recomputing it wastes resources. Deleting the cache implements a lazy‑computation approach: the cache is refreshed only when it is actually needed.

Basic cache inconsistency problem and solution

Problem: If the database is updated first and then the cache deletion fails, the database holds new data while the cache still contains 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 old database value, which is then written back to the cache, preserving consistency.

Analysis of more complex inconsistency issues

When a data change triggers a cache deletion before the database update completes, a concurrent read may find the cache empty, fetch the old database value, and repopulate the cache with stale data. After the database update finishes, the cache now holds outdated information.

Proposed solution

During an update, route the operation (identified by a unique key) to an internal JVM queue. When a read finds the cache empty, it also enqueues a cache‑refresh request for the same key. Each queue is serviced by a single worker thread that processes operations sequentially. This ensures that a delete‑then‑update sequence is completed before any read can repopulate the cache. The queue can filter duplicate cache‑refresh requests to avoid unnecessary work.

High‑concurrency considerations

1. Read request long blocking – Because reads may wait for the queue to finish updating the cache, time‑outs must be configured to guarantee that each read returns within an acceptable window.

2. Read request concurrency overload – In burst scenarios, many reads may block simultaneously, so stress testing is needed to verify that the system can handle the peak load without excessive latency.

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

4. Hot‑item routing imbalance – If a particular item receives a disproportionate amount of read/write traffic, its queue may become a bottleneck; scaling out with additional instances or sharding can mitigate this.