Best Practices for Redis Cache Consistency in Distributed Systems

Background

In distributed environments strong consistency between cache and the underlying database cannot be guaranteed, unlike CPU caches that rely on MESI protocols and hardware memory barriers. Even achieving eventual consistency is difficult because many components (hardware, software, network) can fail.

Overview

The team discusses Redis cache consistency for e‑commerce domains (product, marketing, inventory, order) and aims to propose practical best‑practice recommendations.

Cache Consistency Issues

Database updates generate a series of versions V1‑V6. After a change, the cache should quickly reflect the new version; missing intermediate versions (e.g., V2, V3, V5) does not violate eventual consistency as long as the final cache version matches the final DB version.

How Cache Is Written

Typical write flow consists of four steps: W1 read cache, W2 check existence, W3 assemble data (often requiring a DB query), and W4 write to cache. Uncontrolled delays, especially between W3 and W4, can cause stale data to be written. Using a WriteIfNotExists semantic may mitigate the problem.

Concurrent Write Scenario

When three concurrent writes assemble versions V1‑V3, only one can succeed under WriteIfNotExists. The others must either delete the cache and let a later request rewrite it, or use an atomic operation that writes only if the version is newer.

Detecting Database Changes

Three common approaches are:

Code execution flow : invoke cache‑management code after DB operations (low reliability under crashes).

Transactional messages : emit a transaction message after DB commit and handle cache updates in the consumer (more reliable but adds complexity).

Change logs : listen to DB binlog (e.g., MySQL binlog) and trigger cache actions, offering strong reliability and replay capability.

Best Practice 1 – Invalidate Cache After DB Change

Use a simple put in step W4 and a binlog listener (step D1) to delete the stale cache entry. Drawbacks include occasional stale data under high write/read traffic. Mitigations: set TTL, probabilistic cache reload, business‑specific designs (e.g., avoid cache for order placement), or perform a double delete with a short interval.

Best Practice 2 – Versioned Writes

Cache provides an API that writes only when the incoming version is newer. This requires storing a version field in the DB. It yields better final consistency and avoids the cache‑miss surge caused by deletions.

Summary & Outlook

Practice 1 should be the default, complemented by business‑aware safeguards. Additional solutions include Alibaba XKV (memcache directly on the storage engine for strong consistency) and Tencent DCache (a unified KV view that persists after cache updates).