Published at 30.11.2018
Table of Contents
This blog post takes you on a tour of Redis: its use cases, and example deployments. We hope this article will be useful to you when architecting your Cloud Native applications.
According the website Redis.io:
“Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.”
But what does that actually mean? If it can do all that, then why do we need any other data services. There must be some nuances, some things redis is optimised for, and some caveats we should keep in mind when considering Redis in our applications.
Imagine our app deals with users who are authorized to take different actions within our app. Each time we authenticated [or implicitly renew authorization] a user, we want to derive their authorization for controlling access in your app.
We might consider sending the full list of authorisations [packaged with a nonce and expiry then signed of course] to the user and having them send it to you with each action as proof of authorization. There is nothing wrong, cryptographically, with this approach [provided we use a good standard like JOSE and keep our key material safe], however, if users of our app has more than a couple of authorizations, this becomes very hard to scale, but there is another option we should contemplate.
Instead of sending the list of authorizations to the user, what if we store our users’ authorizations in some form of database and proved the user a unique key (token) that they must send us as proof of authorization? We can then use the key to look up the user’s authorization when they make a request. This of course doesn’t stop us sending the user a copy of their authorizations periodically for building our apps UI [for example], but we have made our authorisation system much more scalable.
Redis has mostly taken over from memcached as the defacto cache for modern web applications. Its binary friendliness along with convenient features make it ideal for caching all kinds of things.
Let’s say that our app involves displaying items to users with some values sorted in varying ways. We have a lot of values in a data service (like MySQL) and we want to display the sorted versions frequently, so doing the sorting calculations each time we display the value is too costly, we need to cache our values in sorted order.
Redis provides quick and basic pub/sub message brokering. Whilst not being as feature rich as other message brokers Redis has its uses.
Picture an app where users collaborate in real time. Real time collaboration means we need a way to inform every user about every other user’s actions. Our users might be being served by different instances of our app, so we need to deal with this communication between the different instances of our app.
Redis is a very useful data service for tying microservices together and following the 12 factor app principles. For workloads focusing on rapidly changing ephemeral data sets where privilege control is not a concern (i.e. apps that you trust enough or less sensitive data) Redis is a strong choice.
For workloads where the data needs protecting (i.e. is sensitive or hard to recreate) then Redis is less suitable and the workload may be better served by another data service (e.g. PostgreSQL, MongoDB, or Elasticsearch).
If Redis has sparked your interest, anynines have a variety of solutions to match your scale, you can get started deploying apps for free on a9s Public PaaS.