Most developers use cache in their application code. But only few developers know advanced patterns such as Read Through Cache. In this article, we will explain the default way of using the cache and compare it with other advanced patterns, especially Read Through Cache.
Cache Aside Model
Request data from the cache using a key. If cache has the data, return it to the caller immediately. If there is no data, we request the persistent storage (DB) for data. After getting the data from the DB, we put it back in the cache with the key. And return the data. We call this Cache Aside model. It is the default way of working with cache for most applications.
Read Through Cache
In Read Through Cache, the application always requests data from the cache. If cache has no data, it is responsible for retrieving the data from the DB using an underlying provider plugin. After retrieving the data, the cache updates itself and returns the data to the calling application.
Cache Aside vs Read Through Cache
Using the Read Through Cache has an important benefit. We always retrieve data from the cache using a key. The calling application is not aware of the database. This makes the code more readable. The code is cleaner.
So, why don’t we have only the Read Through Cache? There is a drawback. It requires writing a provider plugin for database fetch. And it is not a trivial task. The Cache aside strategy is much simpler to implement. Most developers are familiar with writing code that way.
Other Models
Similar to Read Through Cache, we have a Write Through Cache. In this case, we do not update the database directly but through the cache. The cache knows how to update the database using a provider plugin.
Write Behind Cache is a variation of Write Through Cache. It queues all the database updates and does a batch update.