When performing caching, there are several ways to control the behavior of our cache system depending on our requirements. These are called caching strategies, and we can put different caching strategies to work when we have different data requirements.

So, let's see how caching can be implemented to offload a database. Any time we are implementing a caching solution, we treat the cache as a separate data store that can hold some or all of the data being used in our application. The first read request will thus always be directed towards the cache, and the cache will either respond with a piece of data that it has – a so called cache hit - or it will not have the data and that would be a cache miss. When the data is not in the cache, there are several more steps that need to be undertaken. First, we need to direct the read at the database and request the database to provide us with the piece of data, or to perform a complex transaction that will create that piece of data. Once we have the response, we can write to the cache and update the contents so that if another node from our cluster or another user requests that same piece of data, it can be delivered straight from the cache. The following diagram shows how this model functions: 

As mentioned before, there are essentially two ways to control the contents of an ElastiCache cluster:

• Write-through data loading
• Lazy data loading