How to Ensure Cache‑Database Consistency in High‑Traffic Systems

Interview Question

How to guarantee cache‑database dual‑write consistency?

Interviewer Psychology

Using a cache inevitably introduces dual‑write, which brings consistency challenges. The solution must address these.

Analysis

If the system can tolerate occasional inconsistency, avoid serializing read and write requests; otherwise, serialization guarantees consistency but reduces throughput.

Cache Aside Pattern

The classic read/write model: read from cache, fall back to DB if miss, then populate cache; on update, write to DB first then delete the cache.

Why delete cache instead of updating it? Complex cache values may require aggregating data from multiple tables, making direct updates costly. Deleting the cache and lazily recomputing on next read reduces overhead.

Basic Inconsistency Problem and Solution

Problem: update DB then delete cache; if cache deletion fails, DB has new data while cache still holds old data.

Solution: delete cache first, then update DB. If DB update fails, cache remains empty, and subsequent reads will fetch the old DB value and repopulate the cache.

Complex Inconsistency Scenarios

When a write deletes the cache but the DB update is not yet committed, a concurrent read may fetch stale data from the DB and repopulate the cache, leading to divergence.

In high‑traffic environments (millions of requests per day), such race conditions become likely.

Proposed Queue‑Based Solution

Route all operations for a given data item to a single JVM internal queue. Reads that miss the cache enqueue a “refresh” request; writes enqueue a “delete‑then‑update” request. A dedicated worker thread processes the queue serially, ensuring that cache updates occur after the DB commit.

Duplicate cache‑update requests can be filtered to avoid unnecessary work.

When the queue is long, reads may block; therefore, set timeout thresholds and fall back to direct DB reads if needed.

Operational Considerations

Read request latency must stay within acceptable limits.

High write rates can cause queue buildup; scaling out machines and increasing queue instances mitigates this.

Ensure that all operations for the same key are routed to the same service instance (e.g., via Nginx hash routing) to preserve ordering.

Hot‑spot items may overload a single instance; consider sharding or multiple queues.