Read-through caching

As explained in Latency

Read-through caching is a caching strategy in which the cache automatically retrieves missing values from a backing store and returns them to the requester.

Read-through caching makes the cache an active participant in reads. On a miss, it retrieves the key from the backing store, updates itself, and returns the value to the application. The application therefore sees the same lookup interface whether the value was cached or had to be fetched. section 6.3.2

The strategy shifts responsibility from application code into the cache:

• Reduces application-side cache management because the cache coordinates misses, backing-store reads, and cache updates. section 6.3.2
• Requires the cache to understand the data model and transform backing-store results, such as SQL rows, into JSON or another cache format. section 6.3.2
• Can provide transactional guarantees and consistent handling of concurrent cache misses when it coordinates database reads and cache updates. section 6.3.2
• Still exposes backing-store latency on misses, although the cache-to-store path may be shorter and active behavior can hide tail latency. section 6.3.2
• Can use refresh-ahead caching to update entries asynchronously before expiration, reducing the effect of expired values. section 6.3.2

Database-backed key lookup

An application requests a key from the cache. If the key is absent, the cache queries the database, converts the result into a cacheable representation, stores it, and returns it. A later request can be served directly from the cache. section 6.3.2

Figure 6.2 With read-through caching, the client looks up a key from the cache. Unlike with cache-aside caching, the read-through cache queries the database and updates itself on a cache miss.

Trace the request path from application lookup through cache miss, database retrieval, cache update, and response. section 6.3.2

How Latency covers it

How deep it goes

Explains miss handling, data transformation, consistency, coupling, latency, and refresh-ahead, but stops short of implementation code.

Examples

Uses an application lookup backed by a database, with SQL results transformed into JSON or another cache representation.

What it assumes

Assumes familiarity with caches, cache misses, backing stores, databases, and application data formats.

What you can do after

Apply it by placing backing-store retrieval and cache population behind a cache lookup while accounting for coupling, consistency, and tail latency.

How it connects

Connects read-through caching with cache-aside caching, refresh-ahead caching, client-side caching, TTL, cache coherency, and cache replacement policies.

liveBookmanning.com

Read Latency on liveBook Get the book at manning.com

Related concepts

• cache-aside cachingcontrasts with · Cache-aside caching is a pattern in which an application reads from a cache first, retrieves misses from backing storage, and populates the cache.
• databaseuses · A database is an organized collection of persistent data managed by software for storage, retrieval, querying, and modification.
• cachinguses · Caching is the practice of storing reusable data or computation results so later access can avoid repeating retrieval or computation.
• backing storeuses · A backing store is the authoritative storage layer from which a cache obtains values that it does not contain or whose cached copies have expired.
• lazy initializationimplements · Lazy initialization is a technique that postpones creating, retrieving, computing, or loading a value or resource until it is needed.
• write-behind cachinguses · Write-behind caching is a technique that records updates in a cache, acknowledges them, and later propagates them to a backing store.

This explainer was generated by Manning's knowledge graph from the text of Latency. The section links point to the parts of the book it draws on.