Top Five Use Cases for Redis® In-Memory Database Server

Updated on June 22, 2024
Top Five Use Cases for Redis® In-Memory Database Server header image

Introduction

Redis® is an open-source key-value database server based on the NoSql (not only SQL) model. Unlike disk-based traditional Relation Database Management Systems(RDBMS) like MySQL, Redis® stores data in your computer's RAM. This functionality makes Redis® many times faster than even the fastest RDBMS.

The Redis® data structure is comprised of keys and values. That is, instead of storing data in tables and rows, Redis® uses a data dictionary to store a collection of names (keys) and the related data(values). Also, Redis® provides a wide range of data types, including binary-safe strings, sets, lists, hashes, and more.

Redis® was not designed to be used as a central database for applications. However, to keep up with your application's speed, scalability, and high availability, there are several cases where you may need to implement Redis® between your application's frontend and backend.

This guide focuses on the top Redis® use-cases that you can implement in modern-day applications.

1. Redis® as a Cache

Caching is a technique for creating a high-performing application. For instance, if you have an e-commerce application and a web visitor requests a list of products, your application pulls this information from a relational database like MySQL, which stores data to your server's disk. This requires a roundtrip to the disk. The disk I/O operation may be negligible in a small-scale application. However, when your client base increases to millions, like in the case of Amazon or eBay, your application becomes very slow.

This is where the Redis® cache comes into play. To implement the cache, you simply put Redis® in between your client application (for instance, a website, desktop software, or mobile app) and your backend database (for example, MySQL or PostgreSQL). Then, when the first client requests the products' list, you should create a cache in the Redis® server. Your application will serve any subsequent requests from the cache from this point onward.

Here are some guides with working source codes that you can use to implement the Redis® cache in your application:

2. Redis® as a Message Broker

A message broker is an application that allows data to be interchanged between applications. These pieces of software are usually used to minimize delays on the client-side of the application. For instance, a message broker can sit between your application and the main relational database in a mobile money transfer application.

When you tap a button to send money to your friend, your request is queued by the message broker. Then, another worker script either on the same or a different server processes the application in the background. This makes the application highly responsive.

To achieve this functionality, Redis® uses the pub/sub and blocking lists functions (BLPOP and BRPOP). In this paradigm, Redis® acts as a message broker and allows you to create a channel where publishers (front end clients) can send messages (business operations/jobs) that are later consumed by publishers (backend applications) for further processing.

You can read more about implementing Redis® message broker functionalities from the following guides:

3. Redis® as a Session Handler

If your application requires a form of authentication, a good practice is to use sessions. In this approach, you assign your application's users with account names and passwords. Then, in a login form, the end-users can prove their identity by providing the correct credentials. Then, you should look up these details from your database and check whether there is a match or not. In case the latter happens, you simply deny access to your application. Then for successful logins, you assign the user a time-based authentication token and save the value into your database table.

Now, every time the user makes a request, your application makes a roundtrip to the database to check if the authentication token is valid. This approach works well in a small-scale application with a few users, but the application may not handle the scalability needed with millions of users. To address this issue, you can use Redis® to cache the session data.

This requires a single roundtrip to the database. Once you verify the details of the user from your relational database table, you should save the session information in the Redis® server. Next time the user makes a request in your application, you simply validate the session cache from the Redis®.

Follow the guide below to learn how to implement Redis® session handling in your application.

4. Redis as a Leaderboard

Redis® provides the sorted set(ZSET) data structure to allow you to create highly responsive and scalable leaderboards. A leaderboard is a sortable list showing the members, their scores, and current ranks. You can use leaderboards in gaming applications to show players their current ranking depending on other competitors.

Also, Redis® leaderboards are used in fitness tracking applications that require a highly-responsive database to monitor the heart-beat rate, step counts, and more. While you can implement a leaderboard with the traditional RDBMS, the process of storing, retrieving, sorting, and ranking data is very slow when the data grows with time. A leaderboard requires a database that can handle high-speed data ingests and real-time analytics. This is where Redis® comes into play.

The following guide has a working source code that you can use to implement a Redis® leaderboard in your application.

5. Redis® as a Rate Limiter

To prevent end-users from abusing your server resources, you must put a rate-limiting mechanism between the frontend application and the backend service. You can use a disk-based database to log the number of times a user has visited a given resource and lock them out them once they hit a certain threshold. This approach requires your application to make unnecessary roundtrips to the database server.

The best approach is to implement the rate-limiting mechanism in your application is to use an integer-based Redis® key that expires after a set period (for example, 60 minutes). Then, every time a client makes a request to your application, you should increment the integer once and compare the new value with your set limit. If a client exceeds the limit, you should return an error. Since the key is memory-based, it won't hurt your application performance as compared to the RDBMS approach.

The Redis rate-limiting model is discussed below with a working source code.

Conclusion

As you can see from the above examples, Redis® has many practical use-cases for modern-day applications. While the above is not a conclusive list of how you can use Redis®, it's a good startup guide if you're coming from relational databases. Remember, you should always consider a form of in-memory database in your application if you need rapid response times and scalability.