Redis

Most of the initial commits we've covered contain a README file, and those READMEs range from 137 lines (Homebrew) to 173 lines (Next.js) to 168 lines (git). They are manifestos. They explain what the project is, why it exists, how to use it.

The README in Redis's first commit is one line long.

1. The one-line README

Here, in full, is the README file as it appears in the first commit of Redis:

"Check the 'doc' directory. doc/README.html is a good starting point :)"

That's the entire file. Fifteen words and an emoticon. The documentation lives elsewhere, because who would write docs twice.

This is the kind of README that tells you everything you need to know about the author before you have read a line of code. Salvatore Sanfilippo (who everyone on the internet calls antirez) is a programmer with strong opinions about where effort should go. Effort should go into the code and into the documentation. Effort should not go into writing a second copy of the documentation for people who are standing one directory away from the real one. The README is a signpost, not a sermon. Nine of those fifteen words are the location of the real README.

And then, in case you doubted the vibe: the smiley face.

2. The one-line BUGS file

The README is not the only comically short file in the commit. Right next to it is a file called BUGS, which contains exactly this:

"Plese check http://code.google.com/p/redis/issues/list"

Note the typo: "Plese" instead of "Please." In the first commit of a database that currently holds an enormous fraction of the world's cache state, the instruction for reporting bugs contains a misspelled word. Nobody fixed it for some time. It is a beautiful example of the best-is-the-enemy-of-the-shipped school of software development.

There is also a BETATESTING.txt file, which contains a friendly note from antirez to early adopters:

"Hello betatester!

This Redis Server distribution is just a preview, it is by no mean an usable product, but probably it can already give you some feeling about what the final release is going to be."

This file, too, contains a typo ("cotanin" instead of "contain," a few lines down). The commit is, in other words, the work of someone who is shipping fast, who knows his English is not perfect, and who has decided that shipping fast is the higher priority. It is charming in a way that polished first commits are not.

3. The TODO file is a time capsule

The most interesting short file in the commit is TODO, 17 lines of bullet points labeled "BETA 8 TODO." These are the things antirez had not yet done but knew he needed to do before Redis was done being a preview. Reading them now, fifteen years later, is like reading a letter from the past to the future:

BETA 8 TODO
- keys expire
- sunion ssub
- write integers in a special way on disk (and on memory?)
- compact types for disk storing of short strings
- network layer stresser in test in demo
- maxclients directive
- check 'server.dirty' everywere
- replication tests
- command line client. If the last argument of a bulk command is missing
    get it from stdin.
- Make Redis aware of the memory it is using thanks to getrusage() and
    report this info with the INFO command.

Every single one of these things made it into the Redis you use today.

• keys expire → EXPIRE, TTL, PEXPIRE, and the entire keyspace notification system.
• sunion ssub → SUNION, SDIFF, SINTER. The set-algebra commands that make Redis a uniquely good fit for things like recommendation systems and access-control checks.
• replication tests → the Redis replication model, which would become the foundation of Redis Sentinel and Redis Cluster.
• command line client. If the last argument of a bulk command is missing get it from stdin → this exact behavior is still in redis-cli today. You can pipe a file into redis-cli SET mykey and it will read the value from stdin. That was a TODO item in the first commit.
• INFO command: clients, slave/master, requests/second... → still there. INFO is still the primary introspection command in Redis, and the list of things it reports is still, roughly, the list antirez wrote down on day one.

The most striking thing is how short the list is. Eleven TODO items, and eleven major features of modern Redis. antirez already knew what Redis was going to be. The rest was just typing.

4. What's in the commit

110 files, 13,641 lines, mostly C. The core Redis server was already present: the event loop (ae.c, for "a simple event library"), the list implementation (adlist.c), the network code (anet.c, "a networking library"), and the benchmark tool (benchmark.c, 460 lines; antirez cared about performance numbers from day one).

There is also a curious directory: client-libraries/erlang/. On day one, Redis shipped with an Erlang client library. Not a Python one, not a Ruby one, not a Node one. Erlang. At this point in 2009, Redis's audience overlapped significantly with the Erlang crowd, who were doing distributed-systems-by-hand and were hungry for a fast key-value store to offload work to. The Erlang client was imported into the Redis repo from its upstream Mercurial repository, and you can tell because the initial commit also contains these two files from that import:

client-libraries/erlang/.hg_archival.txt
client-libraries/erlang/.hgignore

.hg_archival.txt is a file produced by Mercurial when you export a snapshot of a repo. .hgignore is Mercurial's equivalent of .gitignore. Both of them landed in Redis's git repository because antirez grabbed an archive of the Erlang client's hg repo, copied it into his Redis directory, and committed the whole thing. A tiny archaeological layer of a different version control system, preserved in amber in Redis's git log.

5. The solo-developer database

There is a specific genre of open-source infrastructure that is built by one person with a strong opinion. Redis is the definitive modern example. antirez was the primary author of Redis, start to finish, for over ten years. He did not have a company behind him when he started. He had an idea about how web applications should offload state from SQL, and he wrote a C program to do it, and the program was fast and the program was simple and the program spread.

The "one author, strong opinions" school of database design is responsible for some of the most beloved software in the field: SQLite (D. Richard Hipp), LMDB (Howard Chu), Redis (antirez). The tradeoff is real: these systems tend to be idiosyncratic, to reject popular features, and to be shaped by the personal preferences of the person who writes them. But they also tend to be exceptionally coherent, exceptionally fast, and exceptionally well-documented (in the place the author wanted the docs to live, which is the doc/ directory, not the README :) ).

antirez stepped back from day-to-day Redis development in 2020, handing over maintenance to a team sponsored by Redis Labs (now Redis Ltd.). But the shape of Redis is still the shape he gave it in this commit. The event loop is still ae.c. The network code is still anet.c. The command set has grown, but the commands that were in the original TODO are still the commands most people use.

A one-line README was enough. Everything else followed from the code.

6. Footnotes from the commit log

• The original Redis bug tracker, at code.google.com/p/redis/issues/list, no longer exists. Google Code was shut down in 2016. The URL in the BUGS file is a broken link today. The typo outlived the link.
• antirez's name shows up in the committer field as "antirez," not "Salvatore Sanfilippo." He has used the handle consistently for his entire career.
• Redis was written while antirez was running a real-time web analytics company called Merzia. The need to push data through faster than MySQL could handle is what drove the first version. In that sense, Redis is another "extracted from a real product" project, like Rails.
• The ae.c event library is borrowed (with permission and credit) from Dan Kegel's "c10k" article and a few open-source predecessors. It is one of the very few places where antirez did not write the code himself, and it is credited in the source.