How to Keep Cache and Database Consistent Under High Concurrency?

Cache Aside Pattern

The 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, stores the result in the cache, and returns the data. When updating, the database is updated first, then the cache entry is deleted.

Why delete the cache instead of updating it? In many complex scenarios the cached value is not a direct copy of a single database row; it may require joining multiple tables and performing calculations. Updating such a cache can be expensive, and if the data changes frequently but is rarely read, constantly recomputing the cache wastes resources. Deleting the cache defers the expensive computation until the next read, implementing a lazy‑calculation approach similar to lazy loading in ORM frameworks.

Basic Cache Inconsistency Problem and Solution

Problem: Update the database first, then delete the cache. If the cache deletion fails, the database holds new data while the cache still 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 old database value and later refresh the cache, avoiding inconsistency.

Complex Inconsistency Scenarios

When a data change triggers cache deletion before the database update, a concurrent read may find the cache empty, fetch stale data from the database, and repopulate the cache. After the original write completes, the cache now contains outdated data.

This issue appears in high‑traffic, high‑concurrency environments where many writes occur per second.

Queue‑Based Solution for High Concurrency

Updates are routed based on a unique identifier to an internal JVM queue. Reads that miss the cache also enqueue a cache‑refresh operation for the same identifier. Each queue is serviced by a single worker thread that processes operations sequentially.

When a write arrives, the worker first deletes the cache, then attempts the database update. If a read arrives while the update is pending, it enqueues a cache‑refresh request and waits for the worker to finish the update before returning the fresh value. Duplicate cache‑refresh requests can be deduplicated to avoid unnecessary work.

Key considerations in high‑concurrency scenarios:

Read request blocking: Reads must return within a timeout; excessive queue buildup can cause timeouts and force reads to hit the database directly.

Read request volume: Sudden spikes in reads may overload the service; load testing is required to determine acceptable queue depth.

Routing to the same service instance: Updates and corresponding cache refreshes should be routed to the same instance (e.g., via Nginx hash routing) to preserve ordering.

Hot‑item routing skew: If a particular item receives disproportionate traffic, its queue may become a bottleneck; scaling out with more instances and multiple queues can mitigate this.

Overall, the solution relies on serializing operations per data key, using lazy cache refresh, and carefully tuning queue size, thread count, and routing to maintain consistency without sacrificing performance.