Redis Is The Most Important Tool In My Toolbelt

I remember being a kid and getting my first swiss army knife. I suddenly found myself facing daily problems for which one of the attachments was the perfect solution. It's not that the problems I faced were somehow different, nor that they were unsolvable before. Rather, I now had simple tools that were often a better fit.

Fast-forward to today and I find myself using Redis in much the same way. I just cannot overstate how useful and simple it is to use. Like a swiss army knife, if you are looking at Redis trying to understand what unique problem is solves, then you'll probably miss its true beauty. There isn't anything you can do in Redis that you can't do using something else. The joy of Redis is how simple and intuitive some things are to do. It's also worth mentioning that it has well-documented, predictable and insane performance characteristics.

Every project and every organization should have Redis servers available for developers to leverage. Sometimes you'll use Redis for very specific purposes. But once the server is there, you'll find all types of good reasons to make use of it.

The most basic is as a simple caching engine. Maybe you don't need a full blown memcached setup, but since you already have Redis setup, why not leverage its caching capabilities? Time to live, efficient get/set, drivers that support consistent hashing and so on.

It's also a great way to share information and state across servers or components. I was recently pointed to this project that lets you control feature rollouts using Redis. Of course, that's just one of countless examples you could come up with.

If you need to do real time statistics, Redis is an obvious choice. It's fast and dead simple to use. Here's a cool example of how some people are using Redis for stats.

When I released The Little Introduction To Programming, I used Redis' sets to track email registration: redis.sadd(params[:email]). That's all there was to it

Its pub/sub system, as well as the ability to use lists as a simple queue, are also handy to have around. Again, it might not be as powerful and capable as a full-blown message queue, but if you just need a simple queue (which is quite common), you'll be thankful that there's a Redis box available. I use this aspect of Redis for both jobs.openmymind.net as well as mogade's new Twitter integration feature.

Speaking of the twitter integration, one thing that I wanted to do was throttle how often we'd tweet a message. After we tweet a message on behalf of a game we execute redis.setex("tweets:throttle:#{id}", 300, true). This creates a key in Redis which will automatically expire in 300 seconds. Having this, we simply check for the existence of the key before tweeting: next if redis.exists("tweets:throttle:#{id}"). Again, it isn't that you can't do this with SQL. But you'd have to bind parameters, deal with returned records, either delete records yourself, or do an upsert. It isn't unthinkable. In fact, it isn't even hard. But it's so much simpler and cleaner with Redis.

In the end, Redis is just useful to have around in ways that aren't necessarily obvious until it is. The only downside to Redis, for the time being, is that it isn't trivial to achieve high availability. Redis Cluster which we'll hopefully see this year, will address this limitation.

If you are interested in learning more, you might enjoy the free The Little Redis Book. Or my two part introduction to Redis.