Read-Through

Basic System Design
≈ 2 min read

The application sees only the cache

With Read-Through, the application does not implement separate “miss → database → put” logic. It requests a value from the cache, and the cache itself knows how to load missing data from the primary source.

application
    |
    v
  cache ---- hit ----> value
    |
   miss
    v
cache loader
    |
    v
primary source

After a miss, the loader obtains the value, the cache stores it, and the value is returned to the application. From the perspective of business code, reading looks like access to a single component.

Loading logic becomes centralized

The main difference from Cache-Aside is where responsibility lives. With Cache-Aside, the application implements the miss path, while with Read-Through it is inside the caching layer or a library that provides this interface.

This is convenient when many parts of the code read data in the same way: key construction and loading rules can be kept in one place.

The cost of the abstraction

The cache must now be able to obtain a value from the primary source. If different requests require complex business logic or several sources, the loader can become too smart and lose its simplicity.

A miss also still requires access to the primary store. Read-Through simplifies code and responsibility placement, but it does not remove the cost of the first read.

Cache-Aside and Read-Through solve a similar problem with different placement of logic. The choice is not about which pattern is “faster,” but about where loading rules are easier and safer to maintain.