System Design: Distributed Caching with Redis
In this article, I am going to talk about the design of the cache implementation system with Redis and talk about what cache is and what its uses are!
- What is Cache?
In a quick and clear explanation, the cache can be described as a data store to improve the performance of the data processing. In fact, cache gives you the power to work quickly with data. Let’s talk about the simple usage of the cache system.
For example, you want to restore a user’s profile. This can happen many, many times in a short period of time, and each time it queries the database to get information, which is a costly task.
To improve this process you can save the received information in the cache (in key, value format) and don’t have to work with the database for each request. Then you can pass the stored data to the client from the cache.
The first thing you may have guessed is that:
Cache Reduce DB load.
In the other case, imagine we want to show the average age of the users who registered last week. To do this, we need to do calculations on the database that are repeated with each request which costs a lot.
So instead once you do these calculations and save it in the cache and many times you receive it without involving the database! it’s mean:
Cache Refuses to Recalculate
And both of these processes will help you to respond faster to requests.
- When Should we use Cache?
In fact, the use of cache is not always recommended, for example, if we always want to store user profile information in the cache, the volume of the cache increases and it becomes slow and difficult to work with. Or if we store all the data we have in the cache, then why use the database at all!
There is a policy for this subject that called the policy cache. Let’s look at a few of them together.
LRU (Least recently used)
In this algorithm, we discard the least recently used items first. For example, suppose a cache has only 3 memory cells to store information. And we save the latest biographical changes of the user profile in the cache.
In the first change, we write the desired biography in cache :
“I’m engineer” bio stored in the first cell, Then he change bio to “I’m artist” :
And “I’m artist” go to the first cell, which means the latest changes there. Then he changes bio again and it’s the result :
Therefore, according to this algorithm, In this case, we have the latest changes and changes of the previous 3 steps, and if new data is entered, we save it in the first cell and delete the last cell from the cache.
This was an example of why and when to use cache to get the best results and not confuse cache with the database!
MRU (Most recently used)
In contrast to Least Recently Used (LRU), MRU discards the most recently used items first.
If you want to know more about cache policies, refer to this link
- Why using Redis for Cache?
Look at the picture above, there is a fundamental problem above. Imagine the user changing their password and we want to save the user password in the cache. However, our program is running on 2 separate servers. The user’s request reaches the first server and his password is stored in server 1 cache, but are the server 2 cache the same now? And the change that occurred in the cache of server 1 is also applied in server 2... No, it is not applied and this is where we encounter the problem that the caches are not synced! And our data may be corrupted!
So what is the solution?
To solve this problem, you can use a global cache that is up to date with changes and each server can use it! This is where Redis comes into play :) And this is one of the applications of Radis.
It should be noted that it is not necessary to use the global cache, it is only very important when you have changed the vital data and stored it in the cache
So anyway here is the cache:
This method is much more accurate and structured. You can use the format {key, value} to store your data in the cache.
There are two ways to write data in cache and DB. The first way is Write-Through that you update the cache data first and then the database.
This method is recommended because if the cache does not change in the first step then the whole process is not done, but in the case of Write-Back, if the database data is stored and the cache gets an error, the cache data remains wrong and send the wrong result.
Conclusion
Finally, the use of a cache system is strongly recommended to speed up the response to requests and it is very important that it is implemented with an optimal structure. In this article, we suggested Redis and talked about why we work with it, but there are other methods that perfectly work.
