Cache Update Strategies: Consistency, Concurrency, and Failure Handling

The article analyzes various cache update strategies—including delete‑then‑write, write‑then‑delete, and asynchronous binlog subscription—examining their impact on system throughput, concurrency safety, failure scenarios, and fault detection to ensure data consistency between cache and database.

Top Architect
Top Architect
Top Architect
Cache Update Strategies: Consistency, Concurrency, and Failure Handling

When performing write operations, the cache must be updated to keep data consistent with the database, but ensuring atomicity across the two steps is difficult.

Designing a cache‑update strategy requires considering system throughput impact, concurrency safety, failure impact, and the difficulty of detecting and repairing faults.

There are two basic ways to update the cache: delete stale entries so that a subsequent read repopulates it from the database, or directly overwrite the cache with the new data.

Combining the order of cache and database updates yields four strategies, each prone to a "race" concurrency error that can cause inconsistency.

Update Database then Delete Cache

If the database update succeeds but the cache‑deletion fails, subsequent reads will retrieve stale data from the cache, leading to inconsistency.

Possible concurrency error:

Update Database then Update Cache

This strategy suffers the same problem: if the cache update fails after a successful database write, stale data remains.

Possible concurrency error:

When two write threads conflict, comparing data versions can prevent a thread from overwriting newer data with an older version.

Delete Cache then Update Database

Possible concurrency error illustrated below:

Update Cache then Update Database

If the cache update succeeds but the database update fails, subsequent reads will return unpersisted data, which is dangerous because the cache is volatile; this strategy also carries a high risk due to possible database constraint violations.

Possible concurrency error:

Asynchronous Update

Dual‑write logic is complex and prone to consistency problems; a common solution is to subscribe to database binlog updates (e.g., Alibaba's Canal) and update the cache asynchronously.

This approach still faces similar concurrency issues as the "update DB then delete cache" pattern, but they can be mitigated by using an asynchronous thread and version comparison when writing to the cache.

Possible concurrency error:

Finally, the author provides a collection of BAT interview questions for readers.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendCacheconcurrencyConsistencystrategy
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.