The cache handles the miss
Read-through moves the miss logic out of your application and into the cache itself.
Your app makes one call, always to the cache. On a hit the cache answers from memory. On a miss the cache fetches from the database, stores the result, and returns it.
The entire appeal: your code has a single data path with no branch in it.
You buy this rather than build it. It turns up in products where the cache and the store are already coupled, so you point your client library at the accelerator instead of the table and misses are handled invisibly.
The same shape turns up in library caches that take a loader function and manage the fetch and fill internally. That is read-through inside your own process.
Centralisation is the selling point. With cache-aside, every team writes the miss path slightly differently, and one service that forgets the expiry or stores a differently shaped value creates bugs the others inherit.
With that logic in one place, written and reviewed once, and those bugs stop being possible.
What the coupling costs
You pay in coupling. Your cache now sits on the critical path for every read, hit or miss, so a misconfigured or overloaded cache takes reads down entirely instead of degrading into database reads.
You lose some flexibility too. Your cache stores whatever the loader returns, typically raw items, so caching a computed aggregate across three tables does not fit the model cleanly.
Cold starts need care, because the first wave of misses funnels through the cache layer's connection pool into your database, a choke point you probably never sized.
Read-through fits when a vendor hands it to you cheaply on a store you already run. Choose cache-aside when you want control, unusual key shapes, or a cache failure that degrades instead of taking you down.
Worked example
Diego's team at a gaming company stores player inventories in DynamoDB. Reads spiked during a season launch toward 400,000 per second, and covering that with provisioned read capacity was heading past 30,000 dollars a month. They put DAX in front: a three-node cluster, application SDK swapped from the DynamoDB client to the DAX client, about 40 lines changed. Item reads that hit DAX returned in roughly 400 microseconds instead of the usual 4 ms, and the hit rate ran at 93 percent since players re-read their own inventory constantly. DynamoDB read spend dropped by close to 90 percent. The gotcha they documented for the next team: DAX caches with its own TTL, so a support tool that wrote directly to DynamoDB showed stale inventory for up to 5 minutes until they routed it through the same path.