Redis Manifesto

Tuesday, 01 March 11
Many times I don't know what to exactly reply to feature requests, or questions about why things in Redis are done in a specific way. Most of the time the questions make a lot of sense, there is not just a way to make things in programming, a lot is about your taste, feeling, and ideas about how software should be written. So I tried to condense my feelings about Redis and software development in general in this short manifest, that I'll include in the Redis distribution. There are an infinite number of ways of doing things, this is just the one I and a good part of the Redis community like.

Redis Manifesto

  • 1 - A DSL for Abstract Data Types. Redis is a DSL (Domain Specific Language) that manipulates abstract data types and implemented as a TCP daemon. Commands manipulate a key space where keys are binary-safe strings and values are different kinds of abstract data types. Every data type represents an abstract version of a fundamental data structure. For instance Redis Lists are an abstract representation of linked lists. In Redis, the essence of a data type isn't just the kind of operations that the data types support, but also the space and time complexity of the data type and the operations performed upon it.
  • 2 - Memory storage is #1. The Redis data set, composed of defined key-value pairs, is primarily stored in the computer's memory. The amount of memory in all kinds of computers, including entry-level servers, is increasing significantly each year. Memory is fast, and allows Redis to have very predictable performance. Datasets composed of 10k or 40 millions keys will perform similarly. Complex data types like Redis Sorted Sets are easy to implement and manipulate in memory with good performance, making Redis very simple. Redis will continue to explore alternative options (where data can be optionally stored on disk, say) but the main goal of the project remains the development of an in-memory database.
  • 3 - Fundamental data structures for a fundamental API. The Redis API is a direct consequence of fundamental data structures. APIs can often be arbitrary but not an API that resembles the nature of fundamental data structures. If we ever meet intelligent life forms from another part of the universe, they'll likely know, understand and recognize the same basic data structures we have in our computer science books. Redis will avoid intermediate layers in API, so that the complexity is obvious and more complex operations can be performed as the sum of the basic operations.
  • 4 - Code is like a poem; it's not just something we write to reach some practical result. Sometimes people that are far from the Redis philosophy suggest using other code written by other authors (frequently in other languages) in order to implement something Redis currently lacks. But to us this is like if Shakespeare decided to end Enrico IV using the Paradiso from the Divina Commedia. Is using any external code a bad idea? Not at all. Like in "One Thousand and One Nights" smaller self contained stories are embedded in a bigger story, we'll be happy to use beautiful self contained libraries when needed. At the same time, when writing the Redis story we're trying to write smaller stories that will fit in to other code.
  • 5 - We're against complexity. We believe designing systems is a fight against complexity. We'll accept to fight the complexity when it's worthwhile but we'll try hard to recognize when a small feature is not worth 1000s of lines of code. Most of the time the best way to fight complexity is by not creating it at all.
  • 6 - Two levels of API. The Redis API has two levels: 1) a subset of the API fits naturally into a distributed version of Redis and 2) a more complex API that supports multi-key operations. Both are useful if used judiciously but there's no way to make the more complex multi-keys API distributed in an opaque way without violating our other principles. We don't want to provide the illusion of something that will work magically when actually it can't in all cases. Instead we'll provide commands to quickly migrate keys from one instance to another to perform multi-key operations and expose the tradeoffs to the user.
  • 7 - We optimize for joy. We believe writing code is a lot of hard work, and the only way it can be worth is by enjoying it. When there is no longer joy in writing code, the best thing to do is stop. To prevent this, we'll avoid taking paths that will make Redis less of a joy to develop.
Thanks to Peter Cooper for reading the draft and helping to make it better.
Posted at 09:16:05 | permalink | 24 comments | print
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.

Note: you'll not see this box again if you are a usual reader.


Baishampayan Ghose writes:
01 Mar 11, 10:13:45
smerickson writes:
01 Mar 11, 10:28:21
this is brilliant. every library and product should have something like this.
mkrecny writes:
01 Mar 11, 10:53:20
So say we all
Winfield Peterson writes:
01 Mar 11, 11:05:43
Beautiful stuff. Reminds me of why I prefer Redis over the wide field of key-value and more generic NoSQL stores for most things.
dan writes:
01 Mar 11, 11:18:55
I think you are doing everything right. Keep it simple. Keep it joyful.
rch writes:
01 Mar 11, 11:44:29
well done
IPv6 writes:
01 Mar 11, 11:49:23
nice to hear such wonderfull things :)
James Sun writes:
01 Mar 11, 12:10:43
antirez writes:
01 Mar 11, 13:11:18
thank you everybody
Aaron Boxer writes:
01 Mar 11, 13:15:19
Reading this makes me very happy.

Viva La Rivoluzione Redis !!!
Locke writes:
01 Mar 11, 13:18:56
Well said!
Szymon Jez writes:
01 Mar 11, 13:39:16
Fareesh Vijayarangam writes:
01 Mar 11, 16:03:23
Good going!
Hans writes:
01 Mar 11, 16:30:05
I somewhat disagree with point 4. It sounds childish to me. Code is not poetry. Well, at least that's not its primary function.
Peter Mescalchin writes:
01 Mar 11, 17:30:51
Keep it up guys - as others have often said, the lack of complexity is why I love using Redis. And having used it many a time in production you know you can always depend on it to perform when called to task.
Jon writes:
01 Mar 11, 22:46:50
I too also think #4 is a bit iffy. I think you mean there is a coding style guideline that the project follows. And all contributors that wish to have their code merged must follow the guideline.

Just saying it is "poetry" is too vague and will only discourage people from contributing to the project. But maybe that is what you want?
Bratish Goswami writes:
02 Mar 11, 00:21:44
Like the whole article but #4.

Love #4 :)
yes writes:
02 Mar 11, 05:02:22
@hans, I think what he is trying to say is that it has clarity and consistency of voice. Code is definitely for humans, otherwise code would be written in binary and be a complete utter fully functional mess, much like DNA.

Strength through simplicity.
Diego Pacheco writes:
02 Mar 11, 16:31:07
Simply Beautiful
Arun Srinivasan writes:
02 Mar 11, 20:14:26
This is a very sensible manifesto! And personally I believe Code is Poetry.
Ganesh writes:
04 Mar 11, 15:42:41
I love "simplicity"
JK writes:
05 Mar 11, 01:52:50
case != poet {
case (poem) == true { (redis.manifesto) = true;
if == newbie { (redis) }
akram writes:
05 Mar 11, 11:16:23
Wonderful. This site is super fast. if it's done in redis. I am in
Antonio Gagliardi writes:
30 Mar 11, 09:29:16
A quotes for you:
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

Greatest work!
comments closed