Cache-Aside (Lazy Loading)
Cache-aside is the most common caching strategy available. It checks the cache first to determine whether the data is available. If the data is available (a cache hit), the cached data is returned otherwise (a cache miss), the database is queried for the data. The cache is then populated with the data and the data is returned to the caller.
In this approach, the cache contains only data that the application actually requests, which helps keep the cache size small. But the response time for initial requests is greater due to the cache miss which leads to additional roundtrips to the cache and database.
In this approach, the cache is updated immediately following a database update. This approach is almost always implemented along with lazy loading. In this approach, the likelihood that data will be found in the cache is higher since the cache is in sync with the database. But the problem is that infrequently-requested data is also available in the cache which is not efficient.
Redis is an in-memory dictionary for super-fast read-and-write caching and data storage. Because it stores the data in RAM it can handle millions of data in less than 1 millisecond. The problem with storing data in RAM is that if the system reboots we lose data. For addressing this issue they've introduced two approaches for persisting data in hard disk or network storage.
RDB stands for Redis Database Backup takes snapshots of the data periodically and every once in a while it dumps all the data in the RAM into hard in a compressed format. The rule for dumping data could be based on the time or amount of changed data.
AOF stands for Append Only File and it appends the data to a log file every second or with every change in the data or when the OS is free. The problem with this approach is that it leads to a large log file since it only adds to a file and the log file becomes large over time.
Redis reconstructs the data from the log file or dump file while starting up and automatically stores the data in RAM on disk while shutting down the service. The RDB approach is faster but in the worst case, we might lose the data between snapshots. With AOF we can lose data too but because the gap between saving data is smaller it is more reliable for persistent data.