Common Cache Problems and Their Solutions: Avalanche, Penetration, Concurrency, and DB‑Cache Inconsistency

1. What is a cache avalanche? How to solve it?

Usually we use a cache to buffer the pressure on the database; if the cache crashes, all requests hit the DB directly, causing the DB to fail and the whole system to go down.

How to solve it?

Two strategies (used together):

Make the cache highly available to prevent cache downtime.

Use a circuit breaker: when the cache is down, limit the traffic that reaches the DB, keep part of the system available, and return default values for the rest of the requests.

2. What is cache penetration? How to solve it?

Explanation 1: A request queries a non‑existent key; the DB also has no record. If an attacker repeatedly performs this, the DB can be overwhelmed.

Solution: Store a placeholder value in the cache for missing keys. When a request finds the placeholder, it does not query the DB again, preventing DB overload.

Explanation 2: A large number of requests query a just‑expired key, causing a surge of DB traffic even though the data is the same.

Solution: Apply double‑checked locking in the request code; this may add latency but avoids DB crashes.

3. What is cache concurrent write conflict? How to solve it?

Explanation: Multiple clients write to the same key; if the write order is wrong, the data becomes inconsistent, and the order cannot be controlled.

Solution: Use a distributed lock (e.g., ZooKeeper) and include timestamps. Only the client that acquires the lock can write, and it compares the current timestamp with the cached timestamp before updating.

4. What is DB‑cache double‑write inconsistency? How to solve it?

Explanation: When writing to both the DB and the cache concurrently, race conditions can cause data inconsistency.

Common update orders:

Update the DB first, then update the cache.

Delete the cache first, then update the DB.

Update the DB first, then delete the cache.

Advantages and disadvantages of each method:

Update DB then update cache: If two requests update simultaneously without a distributed lock, the final cached value may be unpredictable.

Delete cache then update DB: After cache deletion, a client may read stale data and write it back to the cache, causing the cache to hold outdated values.

Two solutions for the second method:

Use a "double delete" approach: perform a second asynchronous delete to prevent stale data from being written back.

Use a queue: when the key is missing, enqueue the operation and execute it serially, ensuring the DB update completes before any read.

Overall, this method is more complex.

Update DB then delete cache: This is the widely used Cache‑Aside pattern. If the cache expires just before the DB update, a client may read old data and later write it back, causing temporary inconsistency.

Two preconditions for this issue:

The cache expires before the write, and a read occurs after the write but before the cache deletion, leading to stale data being set.

Some write operations may lock the table.

If this rare situation occurs, use double delete: record whether any client read the DB during the update; if so, perform a delayed delete after the DB commit.

If the service crashes after the DB update but before the cache deletion, the delete fails; this can be mitigated by subscribing to the DB binlog and deleting the cache accordingly.

References

https://coolshell.cn/articles/17416.html https://www.cnblogs.com/rjzheng/p/9041659.html https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside

Recent Issues

[Issue 07] How Redis implements distributed locks

[Issue 08] Methods under the Object class

[Issue 09] Relationship between hashCode() and equals()

Curated common interview questions and technical knowledge to help developers fill gaps.