Cache Update Design Patterns: Cache Aside, Read/Write Through, and Write‑Behind

Large, high‑concurrency backend services often hit performance bottlenecks at the database layer (e.g., MySQL). To accelerate responses, developers commonly add a fast cache such as Redis, but this introduces cache‑database consistency challenges.

The article points out a common mistaken approach: deleting the cache first, then updating the database, which can leave stale data in the cache under concurrent read/write operations.

Assuming both database and cache updates succeed, four cache‑update design patterns are presented.

Cache Aside Pattern

This widely used pattern works as follows: on a read, the application checks the cache; a miss triggers a database fetch and the result is stored in the cache. On an update, the application writes to the database first and then invalidates the corresponding cache entry.

Cache Aside Pattern

The pattern avoids the “delete‑then‑update” race condition by ensuring the database is updated before the cache is invalidated, though a brief window of inconsistency can still occur.

Read/Write Through Pattern

This approach lets the cache itself act as a proxy for the database, so the application sees a single storage layer. Reads and writes are handled by the cache, which transparently loads from or writes to the underlying database.

Read Through

When a cache miss occurs, the cache automatically loads the data from the database and stores it, making the loading process invisible to the application.

Write Through

On a write, if the key is cached, the cache updates the entry and synchronously writes the change to the database; if the key is not cached, the write goes directly to the database.

Write Behind (Write Back) Pattern

Writes are first applied to the cache only; the cache later flushes changes to the database asynchronously in batches. This yields very high I/O performance but sacrifices strong consistency and can lose data if the cache crashes.

All four patterns are well‑tested engineering best practices; the choice depends on the trade‑off between consistency, latency, and throughput.

Practical optimizations for the “delete‑then‑update” approach include delayed double deletion and asynchronous cache updates via binlog subscription (e.g., Alibaba Canal, Tencent Mysync), which help maintain business‑level consistency.

When strong consistency is required, two‑phase commit (2PC) or Paxos‑style protocols (e.g., XA transactions in Java or MySQL) can be used, though they incur performance penalties.

The article concludes that understanding these classic patterns and the underlying computer‑architecture concepts is essential for building robust backend systems.