If you have worked on a backend in the last decade, you have probably touched Redis. Not always knowingly. It is quietly powering session storage, caching layers, rate limiters, job queues, and real-time leaderboards across most of the apps you use daily. But it did not start as a grand database project. It started as one developer's fix for a problem nobody else was solving well enough.
Who Built Redis, and Why
Redis was created in 2009 by Salvatore Sanfilippo, an Italian developer known online as antirez. He was building LLOOGG, a real-time web log analytics tool, and needed to push huge volumes of analytics events and pull back recent page views fast. MySQL, the default choice at the time, simply could not keep up with that access pattern at scale.
Instead of throwing more servers at the problem, he asked a different question: what if the database just lived in RAM? No disk seeks, no query planner overhead, just data structures in memory with simple, atomic commands on top. That idea became Redis, short for REmote DIctionary Server.
Redis was not designed in a boardroom. It was carved out of a real, specific performance wall, and that is a big part of why it stayed so simple.
What Problem Does Redis Actually Solve?
Traditional databases are built to be durable and consistent first, fast second. Redis flips that priority. By keeping the entire dataset in memory, it gives you:
- Sub-millisecond reads and writes with no disk I/O on the hot path
- Rich data structures out of the box: lists, hashes, sets, sorted sets, streams, and bitmaps, not just strings
- Atomic operations like
INCR,LPUSH, andZADDthat run without explicit locking - A single-threaded core that sounds like a limitation but is actually what makes Redis predictable. No race conditions between commands, no lock contention to debug at 2am
A Quick Example
SET user:1042:session "a8f9c2" EX 3600
INCR page:home:views
ZADD leaderboard 9800 "player_42"
ZRANGE leaderboard 0 9 REV WITHSCORESFour commands, four different problems solved: a session with auto-expiry, an atomic counter, a leaderboard insert, and a top-10 query.
The License Change That Split the Community
For most of its life, Redis shipped under the permissive BSD-3-Clause license. That changed in March 2024, when Redis Ltd. moved future versions to a dual SSPL / RSALv2 license, no longer OSI-approved open source. The community response was immediate. The Valkey project forked from Redis 7.2.4 under the Linux Foundation, picking up backing from AWS, Google Cloud, and others almost overnight.
When Should You Reach for Redis?
- A caching layer in front of a slower primary database
- Session storage that expires automatically
- Rate limiting with a sliding window counter
- Real-time leaderboards or rankings
- A lightweight pub/sub layer or job queue
It is a worse fit when your dataset does not fit comfortably in RAM, when you need strong relational guarantees and complex joins, or when durability requirements mean you cannot tolerate data living primarily in memory.
If you want to go deeper, the official Redis documentation is genuinely well written, and the source code on GitHub is surprisingly approachable if you are curious how a single-threaded event loop handles this much throughput.