RedisConf 2018 - High Level Learnings

I decided to attend RedisConf 2018 because I've used Redis quite a bit in my development career and was interested in learning more about it. My primary uses of Redis thus far have been purely as a caching layer and session storage. In general one of the main takeaways I've had from attending this conference is how easily Redis can be used for so much more. Ending the common thought process of "Redis is just a caching layer" opens your eyes to a much broader world of insanely powerful applications of this incredible technology.

Below are some of the specific items I found most interesting / useful. Note that these are really only the tip of the iceberg and don't even truly dig in to the expansive use cases I learned about.

Using sets with intersections for filtering

I've too often cornered Redis in to being user for a pure key value store. However, use cases with built in data structures like sets tied together with union operations are extremely powerful. A great example of this would be list filtering based on criteria like categories (i.e. a product catalog). The results of operations like this are insanely fast, too!

Bitfields as temporary storage

Using bitfields in Redis can be a super memory efficient way to store small amounts of information about users that can be retreived in O(1) time. There are all sorts of ways this can be used. A quick Google even brought up an access control system developed using this functionality.

Pub/sub for microservices

Using the built in pub/sub functionality seems like it could be useful for microservices as a communiation bus between them. Instead of needing to build out an entire API with endpoints for talking back and forth, the services could all just send and receive messages along the same Redis instance.

As an aside, Redis streams also could be promising to accomplish similar end results. It appears that the API around streams may lend itself to better back and forth communication as well (as opposed to fire and forget).

OBJECT for investigating low level details of keys to avoid memory spikes

Salvatore Sanfilippo, the creator of Redis, mentioned during the conference that he's trying to add more and more observability in to Redis. While the OBJECT call isn't new to Redis, I hadn't really thought much about it before. Internally, the data structure of information stored in Redis can change when certain thresholds are met. Therefore, this command could be very useful when debugging memory spikes or other situations that might occur in a Redis instance.

Lua scripting seems very powerful

Redis is capable of running Lua scripts natively via EVAL. The most simple example of this would be 127.0.0.1:6379> eval "return redis.call('PING')" 0 (assuming you have ran redis-cli). The use cases extend well beyond that obviously. Of particular interest to me was the ability to avoid client to server round trips when running logic against Redis data. Instead, that logic can be moved to a Lua script (which is cached by Redis). In this case Lua has direct access to the Redis data and can manipulate it as needed then simply return the desired result.

Redis modules

With the addition of module support in Redis the use cases are only increasing. Outside of the already amazing modules (like RediSearch), Saltvatore is also expanding upon the module API as part of a dogfooding experiment for one of his other projects. Exciting times ahead!

Again, these are all just high level thoughts around various things I've learned. Believe me, there will be much more research and digging in to some of these topics over the coming months. I've already got quite a few ideas for how I can improve some of my current codebases by using more of the Redis functionality.