A simple introduction to REDIS.

In this article we are going to look at basic introduction to REDIS (Remote Dictionary Server) followed by some practical use cases.

Traditional databases like MySQL, MongoDB, PostgreSql, etc store and retrive the data from disk. Occasionally they might store in memory, but most of the time its stored in disk. So any read or write operation has to be done at the disk level.

A typical flow would be like:

User Request ↔️ Backend server ↔️ Database Server ↔️ Query Parser ↔️ Storage Engine ↔️ Disk

Its a highly abstracted flow. Internally:

If there are too many requests/transactions then they are queued (at, database server level).
Parsing the query takes time.
The incoming data has to be converted/modified as per the disk storage type.
Storage engine should invoke system level calls (OS calls) to write data to disk.
While reading data if the entire requested data is not in a single block of disk then the other part of the data has to be located on the disk.

Above mentioned are few things internally happening for all the database operations we work on. And almost all the steps requires to be stored into RAM(memory) or buffers to forward the commands or data to next step or for execution.

The whole process looks good for normal applications. Think of a use case where thousands of people are participating in an online game and there is a score board, listing the scores of top players in the game. In such case write operations needs to happen at a blazing fast speed.

Thousands of concurrent write operations might delay the accuracy of score if its not in sync with incoming data. In such cases going through the whole above process leads to delayed or inaccurate results. But imagine storing the data into the memory itself so that there is no necessity of accessing the disk every time. It would be very very fast to update or retrieve the data that's already present in the RAM(memory). So that is where redis comes into the picture.

Few other use cases scenarios:

Assume there are thousands of people booking for a newly released movie, the traffic to your booking platform would be very high, in such cases handling the concurrency accurateness is possible only with in memory databases like redis. Possible points for failure:
- Incorrect seats availability. ( Many people might be trying to book a same seat)
- Queuing requests for finishing the payment process (First seat selected user should be given chance for payment page)
- etc
If you are an e-commerce platform during big sale days, the traffic would be immense, even in such cases redis can handle the concurrent transactions in a very very quick manner.

What is redis?

Redis is an open source (BSD licensed), in-memory, key-value, data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries etc.

Theoretically the max available data size while using redis is the size of RAM available for the respective server.

Wait wait, 🤔 so you are saying that redis is an in-memory data store, now what if the server restarts ? As RAM is volatile memory all the data would be lost? 🤯

Yes of course all the data would be lost😭. Nah!! I was just kidding 😜. Now comes the redis data persistence options.

Redis, mainly provides two persistence options:

⇒ The RDB persistence performs snapshots of your dataset at specified programmable intervals. ⇒ The AOF persistence saves every write operation received by the server, right from the time it started. Later it can be played again at server startup, reconstructing the original dataset.

Both the above options will dump the data on to the disk.