The philosophy behind Redis

Salvatore Sanfilippo has, over the lifespan of the project, articulated a distinct view and opinion about the direction and functionality of Redis. In a January 2015 blog post about benchmarking Redis against other databases, Sanfilippo states "I don't want to convince developers to adopt Redis. We just do our best in order to provide a suitable product, and we are happy if people can get work done with it. That's where my marketing wishes end." Sanfilippo and a small core group of Redis developers follow the successful open source governance model of the "benevolent dictator for life" (BDL), where a single person is the ultimate arbitrator of what is committed into the Redis code base. The success of the BDL model, evidenced by open source projects such as Linux kernel development and the Python programming language, is replicated in Redis with Sanfilippo as its primary developer and maintainer.

The BDL model failure modes can be catastrophic if the dictator abandons the project, or worse, is incapacitated through illness or death. Another significant problem that has emerged particularly with Redis is when potential contributors submit pull requests and action on their pull requests is delayed, or more often, ignored. To be fair, the volume of changes that must be examined, tested, and merged into the main code base can be substantial and requires a passionate and dedicated gatekeeper. Linus Torvalds, the initial creator and current BDL for the Linux kernel project, has seen his role evolve more into merging code contributed by others and providing vision and leadership for Linux than writing code himself. Sanfilippo, while acknowledging this problem in a thread on the main Redis e-mail distribution, gives two main reasons for continuing with the current BDL model for Redis:

• A consistent vision for the project's development and future directions
• Accountability for any new or merged changes

Sanfilippo's vision of Redis, as an easy-to-configure, small-memory-footprint (for itself and NOT for its datasets!) and reliable key-value data store has been crucial to the continued rise in Redis's popularity among developers and organizations. His vision does cause tension, especially when new features for Redis are proposed, such as expiring specific sub-values in a hash or offering loadable modules for optional functionality, and these features are rejected for inclusion into Redis. Sanfilippo's desire to keep Redis small and focused on being a memory-only database drives his decisions and development practice.

In 2011 blog post, he elucidated his vision for Redis in a seven-point manifesto for Redis and the Redis development process. Briefly, here are the seven points:

1. A DSL for Abstract Data Types: Redis is a Domain-Specific Language (DSL) for representing and using abstract data structures. These data structures include both the operations (Redis commands) as well as the memory efficiency and time complexity of storing and manipulating those data structures with the associated Redis commands.
2. Memory storage is the #1: By storing all of the data in a computer's RAM, Redis's performance across different systems is more consistent, the various algorithms used to implement these data structures run in a more predictable fashion, and more complex data types such as sorted sets are easier to implement in an in-memory database.
3. Fundamental data structures for a fundamental API: Redis implements a fundamental API for its fundamental data structures. This API, made up of Redis commands and corresponding data structures, tries to intelligibly resemble the data structures the API reads and writes to the computer's memory. Following this design, the Redis API builds more complex operations into the API by building from simpler operations on data structures in the API.
4. Code is like a poem: The most elusive of the seven points in this manifesto. Sanfilippo gives his aesthetic preference for code that fits into a larger narrative of the entire Redis project. His point is that Redis's coding style and approach are geared for humans to construct a narrative. So, inclusion of third-party code depends in part on how well the code fits into the large narrative of Redis and Redis's source code.
5. We're against complexity: Complexity in code is to be avoided. Given a choice to build a small feature with a lot of implementing of code or to forgo the functionality, Redis will take the latter route and forgo the extra complexity and overhead of adding complexity to the code base.
6. Two levels of API: Redis starts with a subset of its API to run in a distributed manner and a larger, more functionality-rich API to support multikey operations. This separation allows significant features such as the Redis master-slave and Redis cluster modes of operation.
7. We optimize for joy: An emotional appeal and very intelligent statement, for developers and operators of technology in general, the thrill of tuning technology to solve difficult and complex problems does elicit feelings of happiness and excitement about the future possibilities of Redis.