The Origin of Redis
The Problem That Started It All
In 2009, an Italian developer named Salvatore Sanfilippo (known online as antirez) was building a real-time web analytics tool called LLOOGG — a service that tracked page views for websites and showed a live log of the last N visitors.
The core problem was simple but brutal:
He needed to store a list of the last 1000 visitors per tracked website, and update it on every page view. He was using MySQL for this. Every page view meant:
Read the list from the database
Append the new visitor
Trim the list to 1000 items
Write it back
At scale, MySQL couldn't keep up. Disk I/O was the bottleneck. The relational model was fundamentally wrong for this shape of data — he didn't need tables, joins, or SQL. He needed a fast, in-memory list that you could push to and pop from atomically.
Why Not Just Use Memcached?
Memcached already existed and was the standard answer for in-memory caching. But it had critical limitations:
It only stored strings — you couldn't store a list natively
No atomic operations on data structures
Data was purely a cache — no persistence, no durability
No pub/sub, no sorted sets, no complex operations
Sanfilippo realized: what if the database itself was the data structure? Instead of storing a blob and manipulating it in application code, the server should natively understand lists, sets, hashes, and sorted sets.
How He Built It
Sanfilippo wrote Redis in C, entirely from scratch, in a matter of weeks. His design philosophy was radical simplicity:
Key decisions:
Everything in RAM — no disk reads on the hot path. RAM was getting cheap. Speed was the goal.
Single-threaded event loop — no locks, no mutexes, no concurrency bugs. One thread handles all commands sequentially using I/O multiplexing (similar to how Node.js works). Because operations are in-memory and microsecond-fast, a single thread saturates the network before it saturates the CPU.
Native data structures — the server understood Lists, Sets, Sorted Sets, Hashes, and Strings as first-class types, not just blobs.
Atomic operations — since it's single-threaded, every command is inherently atomic.
LPUSH,RPOP,INCR— all safe by design.Optional persistence — he added RDB snapshots (fork the process, write to disk) and later AOF (append-only file, log every write). You get speed without sacrificing durability if you want it.
He posted Redis to Hacker News in early 2009 and it immediately caught fire. Hector Martin contributed the first Mac OS X port within 24 hours. DHH (creator of Rails) promoted it heavily. Shortly after, VMware hired Sanfilippo to work on Redis full-time, and later Pivotal and then Redis Labs (now Redis Inc.) took over stewardship.
The Core Insight
The founding insight of Redis was that the mismatch between application data structures and database primitives was causing enormous unnecessary work. Applications were constantly serializing lists into strings, storing them, fetching them, deserializing them, modifying them in code, and writing them back — all because the database didn't understand lists.
Redis said: move the data structure into the server. Let the server be a data structure engine, not a table engine. That one idea — applied with extreme engineering discipline around speed and simplicity — is why Redis became ubiquitous.
