⭕ When using ElastiCache, there are quite a number of methods available to you on how to populate your cache. These different methods of populating a cache are broadly known as caching strategies.
⭕ You might know about AWS ElastiCache, but how well do you know the caching strategies?
This is really important because the optimal caching strategy that I'd use if I were building a gaming app that needs to maintain leaderboard data in near real-time would not necessarily be the same if I had an architecture with three applications and wanted to maintain login state across them.
⭕ AWS ElastiCache broadly allows for two main caching strategies:
✔ Lazy Loading (also known as "cache aside")
✔ Write Through
Lazy Loading
Lazy loading is a caching strategy whereby data is loaded into the cache only when necessary.
Here, when an application requests data, the request searches for data in the cache. If the data is present in the cache (cache hit), Elasticache will return the data to the application. If the data is not present in the cache or has expired (cache miss),the application will forward the query to the database. The data is returned to the appliaction and the application then updates the cache.
Let's explore cache hit and cache miss in more detail.
Cache hit: This occurs when requested data is present in the cache and is current. The following steps take place during a cache hit:
- The application requests data from the cache.
- The Cache checks to see if the requested service is available and up-to-date.
- The requested data is returned to the application.
Cache miss: This occurs when the requested data is not available or has expired.
- The application makes a request to the Cache.
- The Cache finds out that the updated data is not available in the Cache hence will return a null value to the application.
- The application then queries the database service.
- The database returns the up-to-date data directly to the application.
- The application then updates the cache with the new data.
The Lazy Loading strategy is advantageous in various contexts because it only caches needed data, hence preventing the cache from getting filled with unnecessary data that is seldom - if not never - requested. This approach also makes node failures non-fatal. So if a Cache node fails, it gets replaced while the application continues functioning normally by making direct requests to the database service - with a downside of increased latency.
A major drawback of this strategy is that it can result in cache miss penalty. This results in significant increase in latency.
Write Through
Write Through is a Caching strategy whereby data is updated in the Cache as soon as data is written to the database. Unlike Lazy loading, there is synchronization between the cache and the database immediately data is written into the database.
Write Through is a very optimal caching strategy and has the advantage of never having stale data. Data in the cache is always up-to-date.
However Write Through has a downside known as write penalty. This happens because each data written has to complete two trips - a trip to the database and a trip to the cache. This significantly increases latency.
Another disadvantage is cache churn which means that a lot of unnecessary data is written into the cache, which ends up filling the cache volume too soon. This can however be mitigated with a concept called TTL.
Which strategy is right for me?
First of all, it is important to understand that these strategies are not mutually exclusive. It is very possible to combine both strategies to fit your application needs.
Do you have an application that cannot tolerate stale data? You should consider using the Write Through Strategy.
Do you have an application that cannot tolerate a Cache node failure? You should consider the Lazy Loading strategy.
Top comments (0)