Author: Francis NdunguLast Updated: Tue, Feb 8, 2022
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.
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:
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 (
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:
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.
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.
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.
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.