Redis is almost a household name in 2020. With every major tech company moving towards a microservices, service-oriented architecture, Redis is now more important than ever. In this article I am going to share what Redis is and some use cases. More specifically when to use it and when not to use it.
What is Redis?
Redis is an in-memory data structure store, used as a database, cache, and message broker. This was taken directly from the Redis website.
What does that mean.
To look at this we need to look at historic caching solutions. Before we had a cache called Memcached. It is a simple cache that can be executed from the command line or in program. It will store the data in RAM to save time in database loads.
Why is this important? Database loads typically load data from disk, plus additional overhead with computational cost, is much slower than loading data directly from memory. With the invent of SSD’s the difference has drastically decreased, however with large databases this is still true.
Memcached has some simple operations that make it smarter than the general memory dump program, however it is limited in it’s scope.
We can think of Redis in a lot of ways as Memcached 2.0. It can do all the things Memcached can do, plus support some data structures that make additional operations available like
- Sets
- Sorted Sets
- Queues
- Trees
- BitArrays
- Streams
This is very powerful since this enables us to use it for complicated use cases like
- Message broker (Pass messages between 2 different programs connected on the same network)
- Search Indexes
- Bloom Filters
- Real time applications
When to not to use Redis?
Before talking about when to use Redis we should talk about when not to use Redis. Redis is inherently more than a cache, therefore you are typically bound by the memory constraints of the system Redis is hosted on. This means that if you plan on storing huge files, Redis probably isn’t the best choice for you.
- Large Datasets (Memcached is better for you since the data is simple. Memcached can scale easily with instances)
- Simple operations (If you are not going to be using Redis in a micro-services architecture or RT application, there’s very little argument on using Redis vs Memcached)
This is a simple operation in Memcached
Alternatively Redis can get complicated extremely quickly
When to use Redis?
Now we covered when not to use Redis, we should talk about where Redis really shines.
Microservices
If you have a services based architecture, where you have each individual operation handled by an independently owned service, then Redis can be used as a way for all of your services to communicate with one another other
This is important since fundamentally hosting your services in a container system like Docker means all your micro-services will not be able to access to each other without some sort of middleman. Redis in this case acts as a middle man and sends, or ‘brokers’, messages between containers
Real Time Applications
There are time constraints for processing with real time applications. Data continuously streams in which needs to be processed. If you cannot process quickly enough there is a chance of data to be dropped. This leads to a subpar user experience. Redis has simple operations to append data to a stream and effectively creates a ‘backlog’ for your unprocessed data.
Constraints of Redis
- Keys are bound 1:1. They must be deleted before updated
- There are no reserved keywords for strings as strings are stored as bytes
- Maximum key, value size is 512MB
- 2³² maximum keys
- Single machine unless Redis is Clustered
In Conclusion
Building systems is about using the right tool at the right time. Memcached is a great k/v store that is simple and scales horizontally. Redis is a level up and offers a message broker for distributed systems and streams for RT applications. Both have their merits however using the right tool for the job is an important decision for your tech stack.
