Cache Consistency Strategies and Best Practices for the Cache‑Aside Pattern

In high‑traffic systems, databases often cannot meet performance requirements, leading to the widespread use of caches (e.g., Redis) to serve read‑heavy workloads. While caching improves throughput and stability, it introduces consistency challenges because data exists simultaneously in the cache and the database.

1. Significance of Cache Cache replaces slower storage with faster memory, dramatically increasing read performance. It can be implemented as a remote in‑memory store (Redis) or as a local in‑process cache.

2. Consistency Challenges after Introducing Cache Data may become inconsistent when the database is updated but the cache is not, or when the cache is updated before the database succeeds. The window of inconsistency cannot be eliminated completely without sacrificing performance.

3. Four Cache‑Update Strategies

• Update DB → Update Cache : After a successful DB write, the cache is refreshed. In concurrent writes, the order of DB updates and cache updates may diverge, causing stale data (e.g., Thread A writes DB→99 then cache→99, Thread B writes DB→98 then cache→98, resulting in cache 99 vs DB 98).

• Update Cache → Update DB : Updating the cache first can produce wrong data if the DB write later fails, leaving the cache with a value that never persisted.

• Update DB → Delete Cache : Delete the cache after the DB commit. This reduces the inconsistency window to the time between DB commit and cache deletion, typically sub‑millisecond, and is safe for most read‑heavy scenarios.

• Delete Cache → Update DB : Deleting the cache before the DB write can cause a read‑write race where a concurrent read repopulates the cache with stale data before the DB update finishes.

Each strategy is illustrated with timing diagrams and code snippets such as:

data = queryDataRedis(key);
if (data == null) {
    data = queryDataMySQL(key); // cache miss
    if (data != null) {
        updateRedis(key, data); // populate cache
    }
}

Additional code examples for the four strategies are also provided, wrapped in tags.

4. Final Consistency Guarantees Because strong consistency is impractical, the goal is eventual consistency with a minimal inconsistency window (ideally <1 ms). Setting an expiration time on cache entries (e.g., 1 minute) ensures that any missed updates are eventually corrected.

5. Reducing Cache Update Failures Using reliable message queues (MQ) with at‑least‑once delivery can retry cache invalidations. Transactional MQ (e.g., RocketMQ) or a “message table” pattern can guarantee that cache‑deletion messages are eventually sent even if the service crashes.

6. Handling Multi‑Cache Scenarios When a single DB record maps to multiple cache keys (e.g., user profile, leaderboard, daily stats), each key must be invalidated or refreshed. Coordinating these updates via MQ or by subscribing to MySQL binlog (e.g., using Canal) centralizes cache maintenance across services.

7. Recommendations • For read‑dominant workloads, prefer “Update DB → Delete Cache”. • For write‑heavy or read‑write balanced workloads, “Update DB → Update Cache” may be acceptable if the extra inconsistency window is tolerable. • Always set cache TTL and consider MQ‑driven invalidation to handle edge‑case failures. • For complex multi‑key updates, use binlog‑driven or MQ‑driven cache synchronization.